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I.      INTRODUCTION 

Designing  a  new  computer  architecture  is  a  complex  process.  This  process  produces 
a  complicated  device,  composed  of  many"  interdependent  components.  Since  the  final 
product  is  a  piece  of  hardware,  it  is  expensive  and  time-consuming  to  design,  test,  alter, 
and  then  re-test  the  various  components. 

It  is  difficult  to  directly  measure  the  performance  of  new  hardware  as  it  is  being 
designed.  Performance  parameters  include  items  such  as  how  many  memory  accesses 
occur  and  how  many  times  the  registers  exchange  data  in  a  given  time  period  for  a  given 
program.  In  order  to  measure  these  parameters  directly,  cosdy  monitoring  equipment  must 
be  connected  directly  to  the  hardware.  The  problems  of  monitoring  and  testing  become 
even  more  pronounced  when  evaluating  Very  Large  Scale  Integration  (VLSI)  Hardware,  as 
it  may  be  impossible  to  connect  external  monitoring  equipment  to  some  of  the  internal 
components.  It  is  also  important  to  test  the  effects  that  each  component  has  on  all  others. 
These  effects  can  be  both  electronic  and  logical;  only  the  logical  effects  are  addressed  in 
this  thesis. 

One  solution  to  the  problem  of  component  testing  and  hardware  evaluation  is  to 
simulate  the  new  hardware  in  software.  This  allows  separate  testing  of  individual 
components  as  well  as  testing  of  the  complete  system.  A  complete  simulation 
environment  should  model  the  architecture  as  closely  as  possible,  yet  remain  as  general  as 
possible.  Reusability  is  the  main  attraction  of  using  simulation  for  hardware  and  system 
design. 

The  majority  of  computer  architecture  simulations  in  the  past  have  been  implemented 
using  conventional  programming  languages  and  techniques.  This  thesis  examines  the 
advantages  of  implementing  computer  architecture  simulation  using  an  object-oriented  (OO) 
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approach.  Encapsulation  of  methods  and  variables  facilitates  the  reusability  of  code, 
inheritance  and  composition  allow  the  building  of  more  complex  components  and  systems. 
Two  computer  architectures  have  been  simulated  using  Prograph1  (Cox  and  Pietrzykowski, 
1989),  an  object-oriented  programming  (OOP)  language,  as  part  of  this  thesis. 

A.     OBJECT-ORIENTED  PROGRAMMING 

1 .     Object-oriented  programming  terminology 

It  is  assumed  that  the  reader  has  at  least  some  familiarity  with  object-oriented 
programming  concepts.  This  section  provides  a  brief  introduction  to  object-oriented 
programming  and  terminology  as  applied  in  this  thesis. 

Object-oriented  programming  may  be  summarized  by  the  following  equation: 
"object-oriented  =  objects  +  classes  +  inheritance"  (Wegner,  1987,  p.  168) 

The  backbone  of  an  object-oriented  programming  language  is  the  object. 
Objects  are  autonomous  entities  that  respond  to  messages  (operations)  and  have  a  state.  An 
object's  state  is  defined  by  its  variables  (attributes),  and  its  operations  are  defined  via  its 
methods  (procedures).  An  object's  state  can  only  be  manipulated  by  its  methods. 
Therefore,  to  change  an  object's  state  from  the  outside,  a  message  must  be  sent  to  the 
object  telling  it  which  method  to  invoke2. 

A  class  is  a  template  from  which  objects  may  be  created  (Wegner,  1987, 
p.  168).  An  object  is  an  instance  of  a  class.  The  variables  making  up  an  object's  state  can 
be  divided  into  class  variables  and  instance  variables.  A  class  variable  is  defined  as  a 
variable  that  has  the  same  value  for  all  instances  of  a  particular  class.  An  instance  variable 
is  one  that  has  a  unique  value  for  each  instance  of  a  class. 


lPrograph  is  a  trademark  of  The  Gunakara  Sun  Systems,  Ltd  (TGSSystems). 

2This  assumes  an  encapsulated  approach;  although  most  OOP  languages  support  this  idea,  not  all  enforce 
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For  example,  a  class  Person  could  be  defined  which  has  the  instance  variables 

name  (the  unique  identifier  of  this  object),  and  where  (the  current  location  of  the  object), 

and  a  class  variable  People  (a  list  of  names  of  all  the  instances  of  this  class)3.   Three 

instances  of  class  Person  are: 

(name:  cannibal  1, where:  left,  People:  (caniball,  canibal2,  missionary  1)) 
(name:  cannibal2,  where:  right,  People:  (caniball,  canibal2,  missionary  1)) 
(name:  missioinaryl,  where:  left,  People:  (caniball,  canibal2,  missionary  1)) 

Even  though  these  instances  of  Person  each  have  a  different  state,  they  all  share  the  same 

operations,  (e.g.,  walk,  sleep,  etc.),  because  they  are  all  instances  of  the  same  class. 

Inheritance  allows  the  creation  of  classes  of  objects  that  are  almost  like  another 
class  of  objects  with  a  few  incremental  changes  (Stefik  &  Bobrow,  1986,  p.40).  This 
results  in  a  formal  code  sharing  mechanism.  A  subclass  inherits  all  of  the  variables  and 
methods  defined  for  its  superclass.  A  simple  example  of  inheritance  is  when  the  class 
person  (instance  variables:  name,  where;  class  variable;  people  methods:  walk,  sleep) 
is  inherited  by  class  Cannibal.  Thus  Person  is  the  superclass  and  Cannibal  is  the 
subclass.  The  subclass  Cannibal  inherits  all  of  the  variables  and  methods  of  Person 
(i.e.,  the  code  is  shared);  the  user  may  also  add  other  variables  and  methods  in  defining  the 
subclass  Cannibal.  The  inheritance  hierarchy  can  be  many  levels  deep  and  complex. 
Single  Inheritance  is  when  a  class  can  have  only  one  superclass  (usually  referred  to  simply 
as  inheritance).  Multiple  inheritance  occurs  when  a  class  can  have  several  superclasses. 

A  composite  object  (or  aggregate  object)  is  an  object  that  contains  other  objects. 
That  is,  its  variables  may  themselves  be  instances  of  other  classes.  For  example,  an 
airplane  object  can  be  defined  as  containing  the  objects  wings,  propeller,  wheels,  etc;  the 
wing  object  contains  flaps,  covering,  cables,  etc. 


3This  example  is  taken  from  a  classroom  project  involving  the  implementation  of  the  missionaries  and 
cannibals  problem  (CS  4114,  Winter,  1990). 


An  abstract  class  is  a  class  which  does  not  have  any  instances  (Nelson,  1990, 
p.6)4,  while  a  concrete  class  is  one  which  does  have  instances.  For  example,  if  the  class 
Missionary  and  the  class  Cannibal  are  both  subclasses  of  the  class  Person  and  no 
instances  of  Person  are  allowed,  then  the  class  Person  would  be  an  abstract  class. 
However,  both  the  subclasses  inherit  all  of  the  variables  and  methods  defined  for  the  class 
Person.  If  the  classes  Missionary  and  Cannibal  do  have  instances,  then  they  are 
concrete. 

Object-oriented  programming  also  supports  encapsulation.  Encapsulation  is  the 
strict  enforcement  of  information-hiding  (Micallef,  1988,  p.  13).  Encapsulation  refers  to  an 
object's  ability  to  hide  implementation  details  behind  the  object  interface  (i.e.,  the 
operations/methods  defined  for  the  object's  class).  When  a  message  is  sent  to  an  object, 
the  object  performs  a  method  which  may  manipulate  one  or  more  of  the  object's  variables 
without  the  message  sender  being  concerned  with  how  (or  even  if)  those  variables  are 
manipulated. 

2 .     Prograph 

All  programs  implemented  in  this  thesis  use  the  Prograph  programming 
environment  on  the  Macintosh5  computer.  Prograph  is  a  pictorial,  object-oriented  dataflow 
language  (Cox  and  Pietrzykowski,  1989,  p.l).  This  environment  was  chosen  because  it  is 
pictorial  in  nature,  it  easily  describes  class  hierarchies  and  variables,  and  it  is  easy  to  use. 
The  following  discussion  is  not  intended  to  be  a  tutorial  in  Prograph  programming,  but 
rather  to  introduce  the  terminology  and  principles  of  Prograph. 

A  simple  class  hierarchy  represented  in  the  Prograph  environment  is  presented 
in  Figure  1.1.    There  are  three  classes:   Person,  Missionary  and  Cannibal;  each  one 


4Abstract  classes  are  not  enforced  by  Prograph,  or  by  any  OOPL  that  we  know  of  (i.e.,  it  is  only  a 

concept). 

^Macintosh  is  a  trademark  of  Apple  Computer,  Inc. 


depicted  by  a  hexagonal  shaped  icon  in  the  classes  window.  The  icon  is  divided  in  half;  the 
left  half  represents  the  class  and  instance  variables  and  the  right  half  represents  the  methods 
associated  with  the  class.  To  open  the  associated  window  the  user  'double-clicks'  on  the 
desired  half  of  the  icon.  The  links  between  class  Person  and  the  classes  Missionary  and 
Cannibal  indicate  that  Person  is  a  superclass  of  the  classes  Missionary  and 
Cannibal. 


©  Classes 


O 
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Figure   1.1  Example  of  Class  Hierarchy  and  Class  Attributes 


The  attributes  window  of  the  class  Person  is  presented  in  Figure  1.2.  In 
Prograph  a  class  variable  is  referred  to  as  a  class  attribute,  and  an  instance  variable  is  called 
an  instance  attribute.  An  attribute  window  is  denoted  by  the  inverted  triangle  next  to  the 
window  name.  The  class  person,  in  Figure  1.2  has  two  instance  attributes  (name  & 
where)  and  one  class  attribute  (People).  Those  attributes  above  the  horizontal  line 
represent  class  attributes  and  the  attributes  below  the  line  represent  instance  attributes.  A 
class  attribute  is  represented  by  a  small  hexagonal  icon  similar  to  the  class  icon  and  an 
instance  attribute  is  represented  by  an  inverted  triangle. 
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Figure   1.2  Example  of  Class  and  Instance  Attributes 


An  example  of  inherited  attributes  is  presented  in  Figure  1.3.  An  inherited 
attribute  is  represented  by  the  normal  attribute  icon  with  a  small  downward  pointing  arrow. 
Therefore,  the  attributes  People,  name,  and  where  are  inherited  from  class  Person. 
The  attribute  level  is  defined  in  the  class  Cannibal. 
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Figure   1.3  Inherited  Attributes 


A  class'  methods  are  represented  in  the  method  window  as  shown  in  Figure 
1.4.  The  icon  with  a  small  dataflow  diagram  inside  it  next  to  the  window  name  indicates 
that  it  is  a  method  window.  The  six  icons  inside  of  the  window  depict  six  different 
methods  defined  for  the  class  Person.  Double-clicking  on  a  method  icon  will  open  the 
associated  methods  case  window. 
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Figure   1.4  An  Example  of  a  Method  Window 


A  case  window  opened  from  a  method  icon  is  presented  in  Figure  1.5 
(descriptive  comments  are  in  bold  type  outside  of  the  window).  The  window  title  is 
composed  of  the  class  name  and  the  method  name.  In  the  example  the  case  window  shows 
the  method  make  from  the  class  Cannibal.  All  case  windows  have  input  bars  and  output 
bars.  These  bars  are  used  to  pass  data  into  and  out  of  the  method.  The  numbers  1:1  in  the 
window  title  indicate  that  this  is  the  first  case  window  of  one  case(s).  When  there  are 
multiple  cases  of  a  method,  all  cases  must  have  have  the  same  number  of  inputs  (terminals) 
and  outputs  (roots)  on  the  input  and  output  bars.  The  number  of  terminals  or  roots  is 
defined  as  arity.  Since  Prograph  is  a  dataflow  language,  the  data  flows  from  the  top  to  the 
bottom  of  the  case  window,  following  the  datalinks. 
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Figure   1.5  An  Example  of  a  Case  Window 

The  shape  of  the  icon  indicates  what  type  of  operation  will  be  performed  and  the 
name  inside  of  the  icon  determines  which  class,  attribute,  or  method  is  executed.  The  icon 
with  convex  left  and  right  sides  (the  top  leftmost  operation,  containing  the  word 
Cannibal)  of  Figure  1.5  is  a  instance  generator.  This  generator  is  used  to  make  an 
instance  of  the  class  Cannibal .  The  two  operations  with  convex  left  sides  below  the 
Cannibal  instance  generator,  are  set  operations.  The  set  operation  is  used  to  set  the  value 
of  an  instance  or  class  attribute.  The  text  inside  the  icon  determines  which  attribute  will  be 
set.  The  left  terminal  is  used  to  pass  the  particular  instance  to  be  operated  on,  and  the  right 
terminal  is  used  to  input  the  value  the  instances  attribute  is  to  be  set  to. 

The  Update  Class  Attribute  operation  in  Figure  1.5  is  a  Local  Operator. 
Local  operators  are  used  to  reduce  the  clutter  in  a  case  window,  and  are  defined  by  the 
programmer.  The  operations  inside  of  the  local  operator  icon  are  still  logically  inside  of  the 
case  window  in  which  it  resides;  they  are  just  grouped  together  in  an  attempt  to  make  the 
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window  more  readable.  Figure  1.6  shows  the  contents  of  the  local  operator  Update 
Class  Attribute  from  the  Cannibal/make  window.  Notice  that  the  arity  of  this 
window  is  exactly  the  same  as  the  arity  in  the  associated  local  operator  icon  in  the 
Cannibal/make  case  window. 


M\  Update  Class  Attribute 


'Cannibal  Instance 


^attach-r^ 


Cannibal  Instance 


5 


O 


5 


o 


a 


Figure   1.6  An  Example  Of  a  Local  Operator  Window 


The  first  operation  labeled  People  (concave  left  side)  in  Figure  1.6  is  a  get 
operation.  This  get  operation  takes  a  Cannibal  instance  as  input  and  gets  the  value  of  the 
People  class  attribute.  The  operation  in  Figure  1.6  labeled  attach-r  is  an  example  of  a 
primitive  operation.  Primitive  operations  are  supplied  by  the  Prograph  programing 
environment,  and  are  represented  by  an  icon  with  a  horizontal  line  near  the  base  of  the  icon. 
In  this  case  the  instance  of  Cannibal  coming  into  the  window  is  added  to  the  People 
class  attribute  (which  is  a  list)  with  the  attach-r  primitive.  The  People  set  operation 
(convex  left  side)  simply  indicates  that  the  value  of  the  People  class  attribute  has  been  set 
to  the  value  returned  by  the  attach-r  operation. 

There  are  several  ways  of  calling  a  message  to  invoke  a  desired  method  in 
Prograph.    Figure  1 .7  gives  three  examples  of  the  various  representations  of  message 


calling.  The  text  inside  the  operation  boxes  represents  the  message  being  sent.  The 
terminals  above  the  box  are  the  data  passed  to  the  method,  and  the  root  leaving  the  box  is 
the  result  of  invoking  the  method.  Regardless  of  the  form  of  message  passing,  if  the 
method  is  not  found  the  environment  searches  for  a  method  higher  up  in  the  inheritance 
tree.  Operation  A  is  an  example  of  an  explicit  reference.  This  message  tells  the  class 
Cannibal  to  invoke  the  make  method.  Operation  B  is  an  example  of  a  data-determined 
reference.  The  message  will  invoke  the  method  make  from  the  class  that  matches  the 
instance  presented  at  the  left  input  terminal.  Operation  C  is  an  example  of  a  context- 
determined  reference.  This  type  of  message  will  invoke  the  method  make  from  the  class 
that  matches  the  case  window  in  which  the  operation  resides. 


^ 


fl  p fl     q 9       p 

^Cannibal/make^        &£/make^3      ^//make^ 


A.  B.v  C. 


•or 


Figure  1.7  Message  Passing 

Progaph  has  two  ways  to  handle  persistent6  data.  Class  attributes  are  used  to 
store  persistent  data  that  is  related  to  a  specific  class.  This  data  can  only  be  accessed  via  an 
instance  of  that  class.  Persistents  are  used  to  store  persistent  data  that  is  not  class  specific. 
These  persistents  can  be  accessed  globally.  An  example  of  the  use  of  a  persistent  is 
presented  in  Figure  1.8.  The  persistent  is  represented  by  an  oval  icon  (Total  in  Figure 
1.8).  Referring  to  Figure  1.8,  the  top  persistent  (with  the  root)  is  being  read,  and  the 
persistent  on  the  bottom  (with  the  terminal)  is  being  written  to.  Since  Prograph  is  a 
dataflow  language,  program  flow  follows  the  datalinks.  Using  Figure  1.8,  the  first 
persistent  Total  is  read,  then  the  data  is  used  and  manipulated  in  the  present?  operation, 


6Prograph  uses  the  term  persistent  to  describe  data  which  is  not  part  of  a  specific  object 
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followed  by  the  results  being  stored  back  into  the  Total  persistent.   There  is  only  one 
Total  persistent,  but  it  can  be  read  and  written  as  often  as  the  programer  specifies. 


Cannibal/multi  1:1 


w///////////////////////;////s;777n 
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I^Total^ 


TRUE 
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Figure   1.8  Multiplexes,  Persistents  and  Program  Control 

Program  flow  control,  an  important  aspect  of  any  language,  is  implemented 
using  case  control.  As  previously  mentioned,  a  case  window  can  have  multiple  windows. 
When  a  case  has  multiple  windows  there  must  be  a  method  to  control  which  window  will 
be  accessed.  When  Prograph  calls  a  method  containing  multiple  case  windows,  it  will 
always  start  execution  at  the  first  case  window  of  the  series  by  default.  If  the  case  window 
has  any  case  control  it  will  check  that  control  first.  Figure  1.8  also  presents  an  example  of 
a  typical  case  control.  The  box  (labeled  X)  in  the  upper  right  of  the  window  is  a  simple 
case  control.  The  X  indicates  that  if  the  data  that  arrives  at  the  control's  terminal  does  not 
match  what  is  in  the  control's  box  then  control  will  transfer  to  the  next  case  window  of  the 
series.  There  are  other  control  symbols  to  perform  the  following:  jump  to  next  case  if 
match,  and  terminate  this  method  if  match/no  match. 
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A  multiplex  is  the  multiple  execution  of  a  method,  which  is  represented  as  an 
icon  that  looks  like  a  stack  (i.e.,  several  boxes,  one  on  top  of  the  other).  The  present? 
operation  in  Figure  1.8  is  an  example  of  a  multiplex.  There  are  several  ways  of  controlling 
the  number  of  times  a  particular  multiplex  is  executed.  The  present?  multiplex  in  Figure 
1.8  has  two  multiplex  operators.  A  method  becomes  a  multiplex  when  one  of  the  roots  or 
terminals  is  changed  from  a  simple  root/terminal  to  a  list  or  loop  root/terminal.  The  ellipses 
terminal  on  the  upper  left  of  present?  is  a  list  terminal.  This  terminal  will  cause  present? 
to  execute  once  for  each  element  of  a  list  presented  to  its  list  terminal.  The  root/terminal  pair 
of  arrows  on  the  right  of  present?  is  a  loop  multiplex.  These  always  come  in  pairs.  This 
allows  the  multiplex  method  to  pass  variables  from  one  execution  of  the  multiplex  method 
to  the  next  execution.  The  data  is  passed  to  the  method  on  the  first  execution,  the  method 
uses/alters  this  data  and  passes  it  out  of  the  loop  multiplex  where  it  will  be  passed  to  the 
input  of  the  present  multiplex  method  as  its  execution  continues  or  it  will  be  passed  as 
output  upon  termination. 

This  section  has  presented  the  most  basic  essentials  of  Prograph  to  give  the 
reader  enough  information  to  understand  the  Prograph  programs  used  in  this  thesis.  For 
more  information  on  Prograph,  please  see  the  Prograph  Reference  Manual  (The  Gunakara 
Sun  Systems,  1990). 

B .     COMPUTER  ARCHITECTURE 
1 .     Computer  Microarchitecture 

The  microarchitecture  level  of  a  computer  is  the  level  that  directly  interacts  with 
the  actual  hardware.  This  is  the  level  of  the  computer  that  will  be  simulated  in  this  thesis. 
We  chose  this  level  because  it  is  easy  to  pick  real  components  and  model  them  as  software 
objects.  The  components  defined  in  this  section  are  implemented  as  objects/classes  in  the 
following  chapters. 
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Most  computers  have  several  common  components,  including:  registers, 
memories,  buses,  arithmetic  logic  units  (ALUs),  and  multiplexers  (muxs).  The  computer's 
micToacrchitecture  is  controlled  either  by  a  microprogram  or  by  hardwired  decoding.  This 
thesis  discusses  only  microarchitectures  that  are  controlled  by  a  microprogram.  The 
purpose  of  the  microprogram  is  to  "control  the  machine's  registers,  memories,  buses, 
ALUs,  and  other  hardware  components"  (Tanenbaum,  1984,  p.l  18).  This  section  provides 
a  brief  introduction  to  the  microarchitecture  level  components  of  a  typical  computer. 

All  processors  (often  referred  to  as  the  central  processing  unit  or  CPU)  contain 
at  least  a  small  number  of  registers.  Registers  are  located  on  the  CPU  chip  and  are  used  to 
store  data.  A  register  is  characterized  by  the  number  of  bits  of  data  it  can  hold.  For 
example,  if  a  register  can  hold  16  bits  it  is  referred  to  as  a  16  bit  register.  The  register's 
short  access  time  is  due  to  the  simple  circuitry  required  to  determine  the  register  being 
accessed  (i.  e.,  a  relatively  small  number  of  logic  gates),  and  also  because  the  register  is 
contained  in  the  CPU  chip.  The  CPU  typically  has  general  purpose  registers  which  are 
used  for  storing  and  retrieving  data  encountered  in  instruction  execution,  as  well  as 
registers  which  have  some  specific  function(s),  such  as  the  program  counter  (PC),  stack 
pointer  (SP),  instruction  register  (IR),  and  accumulator  (AC).  All  of  the  registers  together 
are  often  referred  to  as  a  register  bank.. 

A  computer's  memory  is  similar  in  construction  to  a  register  bank,  except  that 
the  memory  is  much  larger  and  is  located  some  distance  from  the  CPU  (i.e.,  usually  not  on 
the  CPU  chip  itself);  memory  is  also  slower  than  registers.  Typically,  a  memory  bank 
consists  of  many  thousand  locations.  Like  registers,  memory  is  characterized  by  the 
number  of  bits  of  data  each  location  can  hold.  It  is  also  characterized  by  the  number  of 
memory  locations  possible.  One  of  the  reasons  that  memory  is  slower  than  registers  is  that 
it  has  many  more  locations  which  can  be  accessed.  The  larger  the  number  of  locations  to 
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access;  the  more  digital  logic  required  to  determine  the  access  point.  The  increase  in  the 
amount  of  access  logic  increases  the  time  delay  of  the  signals,  thus  producing  a  time  delay 
for  the  desired  data  to  be  returned. 

Data  passed  into  memory  is  communicated  via  the  Memory  Buffer  Register 
(MBR),  while  the  desired  address  of  the  data  (location  of  where  the  data  is  to  be  stored)  is 
loaded  into  the  Memory  Address  Register  (MAR).  A  write  control  is  activated  causing  the 
value  in  the  MBR  to  be  stored  into  the  desired  memory  location.  To  read  a  value  from  a 
particular  location  in  the  memory  the  process  is  reversed  using  a  read  control.  Thus,  the 
memory  bank  interfaces  with  the  rest  of  the  world  via  an  MAR,  MBR,  and  two  control 
signals. 

A  bus  is  used  to  transmit  signals  from  one  device  to  another.  Physically,  a  bus 
is  a  collection  of  wires  that  transmit  a  group  of  signals  in  parallel  from  one  location  to 
another.  Many  devices  can  be  physically  connected  to  the  same  bus.  The  bus  is  considered 
to  be  an  inert  device.  That  is,  if  data  is  electrically  placed  on  one  end  of  the  bus,  the 
information  will  show  up  on  the  other  end.  The  bus  itself  does  not  actively  control  the 
signals;  rather,  the  bus  is  controlled  by  the  equipment  connected  to  it  If  multiple  devices 
attempt  to  transmit  simultaneously,  the  values  of  each  bit  of  the  bus  will  be  garbled  and  the 
data  will  be  useless.  Thus,  many  devices  can  simultaneously  read  data  from  the  bus,  but 
only  one  device  may  be  transmitting  at  any  time.  Therefore,  there  arises  a  need  for  some 
central  controlling  device  to  synchronize  the  control  of  all  devices  writing  on  the  bus.  This 
will  be  discussed  later. 

Devices  may  receive  inputs  from  several  other  devices/buses,  but  can  only 
process  one  input  at  a  time.  This  gives  rise  to  the  need  for  a  multiplexer.  A  multiplexer  is  a 
device  that  has  several  data  input  lines  and  a  single  data  output  line.  It  also  has  several 
control  inputs  that  determine  which  data  input  will  be  selected.  The  output  of  the 
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multiplexer  is  connected  to  the  input  line  of  the  device,  and  data  selection  is  based  on  the 
multiplexer  control  signal.  A  multiplexer  has  2n  data  inputs  and  therefore  has  n  control 
inputs. 

The  heart  of  the  computer  is  the  Arithmetic  Logic  Unit  (ALU).  The  ALU 
typically  has  two  inputs  for  data,  one  output  for  data,  several  control  inputs,  and  several 
result  output  indicators.  The  control  inputs  are  used  to  select  the  operation(s)  to  be 
performed  on  the  input  data.  Standard  ALU  operations  typically  include:  AND,  OR, 
NOT,  and  ADD.  The  result  output  indicators  are  simple  one  bit  signals  which  indicate  that 
output  of  the  ALU  is  negative,  zero,  overflow,  etc.  Shifters  are  used  to  shift  the  bits  of  an 
input  to  the  left  or  right  depending  on  the  input  control  signals.  The  shifter  may  be  placed 
at  the  output  of  an  ALU,  or  it  may  be  a  part  of  the  ALU  itself. 

This  section  has  addressed  the  many  components  typically  found  in  the  data 
path  side  of  a  microarchitecture.  A  typical  data  path  taken  from  Tanenbaum  (Tanenbaum, 
1984,  pp.127)  is  shown  in  Figure  1.9.  It  includes  a  bank  of  registers,  an  ALU,  a  shifter,  a 
Memory  (including  MBR  and  MAR)  and  an  Amux  (multiplexer). 
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Figure   1.9  Data  Path  (Tanenbaum,  1984,  p.127) 

Figure  1.9  shows  many  devices  along  with  input  signals  (Frj,  Fi,  So,  etc),  and 

output  signals  (N  and  Z).  The  input  signals  are  generated  from  the  control  side  of  the 
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microarchitecture.  The  control  side  is  presented  along  with  the  data  path  in  Figure  1.10. 
The  control  devices  consist  of:  the  Micro  instruction  register  (MIR),  the  Control  Store,  and 
the  Microprogram  counter  (MFC). 
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Figure    1.10  Example  Microarchitecture  (Tanenbaumbaum,  1984,  p.  132) 

The  control   store  holds  the  entire  microprogram,  which  consists  of 

microinstructions.  When  a  microinstruction  is  read  from  the  control  store,  it  is  placed  in 

the  MIR.  The  MIR  has  output  leads  from  each  control  field  to  all  of  the  control  inputs  of 

each  device  in  the  data  path  side  of  the  machine.  The  sequence  of  microinstructions  is 
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controlled  by  the  MPC.  The  MPC  sends  its  counter  value  to  the  control  store,  the 
appropriate  microinstruction  is  retrieved  from  the  control  store  and  placed  into  the  MIR, 
and  then  the  MPC  is  incremented  or  changed  depending  on  the  output  status  signals  of  the 
ALU.  This  process  repeats  as  the  microprogram  execution  continues. 

This  section  has  introduced  the  many  devices  found  in  a  typical  computer 
microarchitecture.  The  data  path  consists  of  registers,  memory,  ALU,  shifter,  buses  and 
multiplexers.  It  is  controlled  by  the  micioprogram  which  is  implemented  in  the  MPC, 
control  store,  and  MIR.  Each  microinstruction  controls  the  entire  microarchitecture's 
device  control  inputs.  It  is  the  continuous  cycling  of  the  microprogram  which  controls  the 
fetching,  decoding,  and  executing  of  higher  level  instructions.  These  components  will  be 
seen  again  in  Chapter  HI  where  they  will  be"  simulated  as  software  objects. 
2 .     Simulation  of  Computer  Architectures 

Simulation  of  computer  architecture  is  the  use  of  a  computer  program  on  one 
computer  to  model  the  performance  of  another  computer.  Papazoglou,  et.  al.  says  that 
"Simulative  modelling,  like  every  other  modelling  approach,  does  offer  the  option  that  the 
working  representation  of  a  not  yet  existing  system  is  possible"  (Papazoglou,  Pawlak,  and 
Wrona,  1989,  p.l).  In  the  past,  computer  architectures  have  been  modeled  using  classic 
structured  programming  languages.  Only  recently  have  object-oriented  languages  begun  to 
be  used.  To  model  a  specific  architecture  via  a  conventional  language,  a  specific  program 
was  written  to  model  that  architecture.  Whenever  a  simulation  of  a  new  architecture  was 
needed,  an  entire  new  program  was  written  to  support  the  simulation.  Papazoglou  et.  al. 
outlines  the  following  requirements  for  modeling  an  architecture  (Papazoglou,  Pawlak  and 

Wrona,  1989,  p.  213): 

•  the  model  must  have  the  same  logical  structure  as  the  modelled  computer  system. 

•  it  must  comprise  an  integrated  model  of  both  the  complete  system  hardware  and 

software. 
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•  it  should  be  able  to  model  the  different  parts  of  the  system  at  different  levels  of 

abstraction. 

•  it  should  allow  different  sets  of  output  statistics  each  time  it  is  rerun  with  a  new  set  of 

input  parameters,  and  like  any  well  disciplined  good  program  it  is  structured, 
modular,  reliable,  efficient  and  extensible. 

Modeling  a  computer  architecture  in  an  OOP  language  fulfills  all  four  of  these 

requirements,  and  particularly  excels  with  the  last  two. 

C .     OVERVIEW 

Chapter  II  is  a  detailed  survey  of  the  literature  pertaining  to  previous  work  completed 
in  the  areas  of  computer  modeling  and  object-oriented  design.  Chapter  III  is  a  detailed 
discussion  of  the  implementation  of  the  computer  programs  (developed  in  Prograph) 
simulating  various  computer  architectures  (the  actual  code  is  included  in  appendices  C  and 
D).  Chapter  IV  presents  the  conclusions  of  this  research  effort,  along  with 
recommendations  for  future  research  and  a  summary  of  the  thesis. 
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II.     REVIEW  OF  THE  LITERATURE 

Object-oriented  simulation  of  computer  architectures  is  still  in  its  infancy.  The 
majority  of  the  effort  is  in  the  simulation  of  multiprocessor  systems.  Most  of  the  simulator 
systems  that  were  reviewed  have  a  very  simple  text  based  user  interface;  only  one  group  is 
working  on  a  simulator  in  which  the  main  concern  is  the  user  interface  and  its  ease  of  use. 
Only  one  group  was  found  to  be  interested  in  hardware  simulation  for  classroom 
instruction  purposes.  Some  groups  emphasize  the  usefulness  of  the  object-oriented 
approach  for  the  reuse  of  code. 

To  date,  there  is  no  system  that  incorporates  reusable  objects,  has  an  intuitive  user 
interface,  was  developed  with  commercial  software,  and  runs  on  a  commercially  available 
microcomputer.  Of  course,  a  system  that  meets  these  objectives  would  also  be  economical 
enough  to  be  available  for  classroom  use.  This  is  because  most  systems  are  not  being  built 
using  commercially  available  software.  This  section  discusses  the  various  research  in  the 
field  of  architecture  simulation,  with  an  emphasis  on  object-oriented  approaches. 

A .     SIMULATION  OF  COMPUTER  ARCHITECTURES 

A  system  developed  at  Acadia  University  uses  a  Pascal-like  Register  Transfer  Level 
Language  (RTLL)  that  operates  on  microcomputers  (Tomek,  1985).  This  system  was 
designed  for  the  instruction  of  computer  organization  and  architecture.  They  point  out  there 
is  currently  very  little  educational  software  in  this  field.  Their  package  allows  the  user  to 
"write  descriptions  of  simpler  CPU's,  controllers  and  similar  devices  and  experiment  with 
their  operation"  (Tomek,  1985,  p.493).  The  package  consists  of  the  following  modules: 
RTLL  description  editor,  RTLL  simulator,  Screen  layout  generator,  Memory  file  generator, 
System  description  generator,  and  Organization  descriptor. 
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The  RTLL  description  editor  is  a  syntax-directed  editor  used  to  develop  an  RTLL 
program.  The  RTLL  simulator  executes  the  program  developed  by  the  RTLL  description 
editor.  The  Screen  layout  generator  "allows  the  user  to  specify  the  format  in  which  the 
results  of  the  simulation  are  to  appear  on  the  screen"  (Tomek,  1985,  p.494).  The  memory 
file  generator  allows  manipulation  and  loading  of  the  memories'  contents.  The  system 
description  generator  specifies  CPU  interfaces  with  other  components.  Finally,  the 
organization  descriptor  is  used  to  specify  the  CPU  organization  and  timing  constraints. 
Unfortunately  they  do  not  describe  the  methodology  used  in  the  development  of  the  system 
or  the  programming  language  used  in  its  implementation. 

Object-oriented  design  has  been  applied  to  multimicrocomputer  hardware  and 
software  simulation  in  the  development  of  the  MUDS  system  (Papazoglou,  Pawlak,  and 
Wrona,  1989).  "MUDS  constitutes  an  extension  of  the  SIMULA  language,  and  has  been 
designed  for  developing  prototypes  of  distributed  software  and  for  appropriately  simulating 
the  extension  of  these  software  prototypes  on  a  model  hardware"  (Papazoglou,  Pawlak, 
and  Wrona,  1989,  p.215).  Thus  the  MUDS  system  is  used  for  the  simulation  of  hardware 
and  software  for  multiprocessor  computers.  They  introduce  the  design  methodology  used 
in  the  development  of  MUDS. 

The  basis  of  MUDS  rests  on  the  development  of  classes  used  to  represent  hardware 
and  software.  These  classes  are  chosen  such  that  "the  structure  of  a  designed 
microcomputer  system  may  be  extended  with  an  arbitrary  number  of  instances  of  the 
classes  being  modelled"  (Papazoglou,  Pawlak  and  Wrona,  1989,  p.216).  They  emphasize 
that  a  powerful  simulator  can  be  attained  with  an  appropriate  object-oriented  language,  but 
it  is  essential  that  a  proper  implementation  of  object-oriented  design  techniques  be  used. 
The  authors  also  show  that  the  advantages  of  an  object-oriented  language  (data  hiding, 
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abstraction,  classes  as  templates,  etc.)  allow  for  a  better  representation  of  the 
hardware/software  being  modeled. 

Modeling  of  a  system  can  occur  at  various  levels,  For  example,  the  microarchitecture 
level,  macroarchitecture  level,  etc.  The  Virtural  Stack  Machine,  a  programming  system  for 
generating  and  interpreting  code  for  von-Neumann  machines  is  an  example  of  one  such 
level  or  several  levels  (Frei,  1989).  A  virtual  stack  machine  (VSM)  simulator  is  used  to 
perform  "VLSI  netlist  logic  design  rule  checks"  (Frei,  1989,  p.5/1).  This  relatively  simple 
architecture,  modeled  at  the  macro  level,  consists  of  three  major  elements:  a  central 
processing  unit,  a  data  stack,  and  a  direct  access  data  memory.  The  instruction  set  for  the 
central  processor  is  implemented  as  methods  in  one  of  the  classes  in  the  hierarchy.  This 
research  concluded,  as  with  other  similar  research,  that  a  class  library  is  needed  for  the 
many  objects,  and  that  object-oriented  design  techniques  greatly  reduce  the  coding  effort. 

Nearly  all  hardware  simulators  have  a  very  simple  user  interface.  Only  one  of  the 
systems  reviewed  considered  the  user  interface  as  an  essential  facet  of  the  simulation 
model.  A  simulator  has  been  developed  that  is  used  for  the  writing  and  debugging  of 
microprograms  for  hardware  under  design  (Sugimoto,  Abe,  Kuroda,  and  Katou,  1988). 
This  system  was  developed  in  a  LISP-based  object-oriented  language,  VEGAMS,  which 
was  also  developed  by  the  authors.  The  user  interface  presents  a  bus  and  component 
structure  which  graphically  represents  the  actual  hardware.  This  graphical  representation 
allows  the  simultaneous  display  of  the  bus,  register,  and  various  other  components  as  the 
simulation  progresses.  Having  all  the  pertinent  data  available  on  the  screen  allows  the 
microprogram  developer  to  quickly  realize  mistakes  and  correct  them  immediately.  Another 
feature  is  the  representation  of  data  by  color  coding.  The  microprogram  is  displayed  in  an 
assembly  language  format  and  an  editor  is  provided  for  the  system.  This  allows  the  user  to 
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alter  the  microprogram  and  reenter  it  into  the  control  store  while  remaining  in  a  single 
application. 

One  of  the  system's  major  features  is  its  ability  to  stop  at  a  breakpoint  and  roll-back 
the  execution  to  some  earlier  time.  This  allows  the  user  to  examine  the  state  variables  at 
that  time.  The  user  can  alter  any  variables  and  change  the  microprogram  and  continue 
execution  from  that  point.  The  roll-back  capability  is  implemented  by  keeping  a  complex 
linking  of  objects  over  time.  Thus,  to  roll-back  to  a  certain  cycle  number,  the  appropriate 
pointer  is  referenced  and  its  data  is  loaded. 

Although  some  portions  of  code  are  hardware  specific,  a  significant  portion  is 
common  to  almost  all  computer  architectures.  It  is  claimed  that  developing  simulators 
using  an  object-oriented  language  lead  to  approximately  62%  reusability  of  code  for  other 
hardware  simulations.  As  with  other  object-oriented  applications,  the  design  of  the  class 
hierarchy  is  crucial  to  the  extensibility  of  the  code.  (Sugimoto,  Abe,  Kuroda,  &  Katou, 
1988,  p.55) 

Simulation  efforts  are  not  limited  to  only  object-oriented  or  classical  languages.  The 
simulation  of  concurrent  real-time  systems,  using  the  object-based  language  Ada  has  also 
been  investigated  (Mulcare,  1990).  In  the  design  of  real-time  systems,  "superficial  design 
descriptions"  (Mulcare,  1990,  p.  184)  are  performed  prior  to  attempted  implementation.  Of 
course,  this  leads  to  problems  that  appear  during  construction  of  the  system.  A  formal 
design  process  followed  by  a  comprehensive  simulation  of  the  system  is  easily  attainable 
using  Ada  task  types  to  model  the  various  processes  involved.  The  firing  of  a  Pr-T  net 
transition  "may  correspond  to  a  task  entry  call"  (Mulcare,  1990,  p.  186).  Through  the  use 
of  Ada  generic  packages,  any  number  of  various  architecture  components  (tasks)  may  be 
instantiated.  Their  design  methodology  is  described  through  the  example  design  of  a 
simple  bus  with  interacting  components  which  consists  of  specification,  then  Pr-T  net 
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modeling  followed  by  Ada  task/package  coding.  The  results  of  the  experiment  concluded 
that  very  little  effort  was  required  to  model  the  system.  Also,  any  components  modeled  can 
become  a  portion  of  a  growing  reusable  library  of  components.  The  author  emphasizes  that 
"the  Pr-T  net  served  to  focus  the  entire  simulation  development"  (Mulcare,  1990,  p.  189). 

B.     OBJECT-ORIENTED  DESIGN 

There  are  many  textbooks  and  papers  emerging  on  the  subject  of  object-oriented 
design  methodologies.  Unfortunately,  "To  date,  there  is  no  design  methodology  that  is 
universally  accepted  by  the  object-oriented  community"  (de  Paula  &  Nelson,  1991,  p.203). 
After  reviewing  various  textbooks  and  papers,  the  design  methodology  proposed  by  de 
Paula  and  Nelson  was  selected  (because  of  its  ease  of  use)  for  development  of  systems  in 
this  thesis.  The  major  steps  of  their  design  methodology  is  presented  below  (de  Paula  & 
Nelson,  1991,  pp.  204-205): 

( 1 )  Identification  of  the  objects  and  classes. 

(a)  Initial  definition  of  the  objects  and  classes. 

(b)  Analysis  of  the  object's  variables. 

(c)  Analysis  of  the  object's  methods. 

(2)  Refinement  of  the  objects  and  classes. 

(a)  Addition  of  necessary  information. 

(b)  Elimination  of  redundant  information. 

(c)  Determination  of  class  and  instance  variables. 

(d)  Identification  of  composite  objects. 

(3)  Organization  of  the  classes'  into  a  hierarchy. 

(a)  Analysis  of  the  implementation  language. 

(b)  Construction  of  the  hierarchies. 

(c)  Review  of  the  classes'  variables/methods. 

The  power  of  OOP  lies  in  its  natural  ability  to  closely  map  the  system  to  the  actual 
environment  the  programmer  is  trying  to  model.  The  first  step  (Identification  of  the  objects 
and  classes)  of  the  procedure  identifies  the  objects  and  classes  necessary  to  build  the 
desired  model.  Classes  and  objects  can  initially  be  derived  from  the  problem  domain,  from 
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sources  such  as  the  the  following:  Tangible  things  (cars,  houses),  Roles  (pilot, 
programmer),  Events  (birthday,  graduation),  Interactions  (meeting),  People  (manager, 
bricklayer),  Places  (Areas  set  aside  for  people  or  things),  Things  (Physical  objects  that  are 
tangible),  Organizations,  Concepts,  and  Events  (de  Paula  &  Nelson,  1991). 

The  next  step  in  the  design  process  is  "Refinement  of  the  objects  and  classes".  This 
step  examines  the  methods  and  variables  defined  in  the  previous  section.  This  step  outlines 
a  procedure  designed  to  simplify  the  classes  in  preparation  of  building  a  class  hierarchy. 

The  final  step  (Organization  of  The  Classes  Into  a  Hierarchy)  of  the  design  process 
organizes  the  classes  defined  in  the  previous  steps  into  a  class  hierarchy.  Class  hierarchy 
organization  has  some  dependency  on  the  particular  language  used  to  implement  the 
application. 

The  most  important  guideline  de  Paula  and  Nelson  give  for  construction  of  a 
hierarchy  is  to  "factor  common  methods  as  high  as  possible"  (de  Paula  &  Nelson,  1991, 
p. 207).  This  allows  the  common  attributes  (methods  and  variables)  of  a  class  to  be  shared 
by  all  the  subclasses  via  inheritance.  If  two  or  more  classes  have  attributes  in  common  but 
share  no  common  superclass,  an  abstract  class  can  be  created  as  a  superclass  to  allow  these 
common  attributes  to  be  inherited 

de  Paula  and  Nelson  point  out  that  when  reviewing  the  classes'  variables  and 
methods  it  is  necessary  to  look  for  classes  that  inherit  unwanted  variables  and  methods 
from  their  superclasses  (de  Paula  &  Nelson,  1991,  p. 6).  If  the  inheritance  of  unwanted 
variables/methods  cannot  be  removed,  then  some  of  the  classes  may  have  to  be  modified. 

There  is  no  standard  format  for  representing  class  hierarchies.  A  simple  method  for 
specifying  a  class  definition  in  a  language-independent  manner  is  given  by  Nelson  (Nelson, 
1990,  p. 3)  as  presented  in  Figure  2.1.  This  format  is  used  for  representing  classes  in  the 
text  of  this  thesis. 
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Class  <class_name> 

Superclasses:  <superclass_1  >,  <superclass_2>,  ... 

Class  Variables:        <class_var_1>,  <class_var_2>,  ... 
Instance  Variables:  <inst_var_1>,  <inst_var_2>,  ... 
Methods:  <method_name_1>,  <method_name_2>, 


Figure   2.1  Class   Definition 

C.     CONCLUSIONS 

This  chapter  introduced  the  various  research  in  the  area  of  computer  architecture 
simulation.  This  chapter  also  introduced  the  basic  concepts  of  object-oriented  design,  and 
described  the  methodology  used  in  this  work.  It  showed  that  several  of  the  researchers  are 
interested  in  developing  class  libraries  to  model  computer  hardware  objects.  Most  of  the 
researchers  pointed  out  that  the  design  of  the  class  hierarchy  is  the  crucial  portion  of  the 
design  of  any  simulator.  I  feel  that  the  research  oudined  in  this  chapter  demonstrates  a  need 
for  a  system  with  the  following  features:  incorporation  of  reusable  objects,  an  intuitive  user 
interface,  and  development  using  commercial  software  on  a  commercial  microcomputer.  It 
should  also  be  afordable  for  education  purposes. 


26 


III.  SOLUTION 

Chapter  I  introduced  the  concepts  necessary  to  understand  OOP,  Prograph,  and  the 
basic  components  of  a  computer  microarchitecture.  This  chapter  begins  by  discussing  the 
construction  of  a  'generic'  microarchitecture  class  hierarchy  and  the  objects  necessary  to 
simulate  a  typical  computer  microarchitecture.  This  chapter  also  outlines  the  class  hierarchy 
and  program  construction  for  the  implementation  of  two  different  microarchitecture 
simulators. 

A.     DESIGNING     A     'GENERIC     MICROARCHITECTURE     CLASS 
HIERARCHY 

This  thesis  uses  the  object-oriented  design  methodology  presented  in  de  Paula  and 
Nelson's  paper  for  the  construction  of  class  hierarchies  (de  Paula  &  Nelson,  1991). 
Previously  discussed  in  Chapter  II,  the  following  is  an  outline  of  their  design  methodology 

(de  Paula  &  Nelson,  1991,  p.2): 

( 1 )  Identification  of  the  objects  and  classes. 

(a)  Initial  definition  of  the  objects  and  classes. 

(b)  Analysis  of  the  object's  variables. 

(c)  Analysis  of  the  object's  methods. 

(2)  Refinement  of  the  objects  and  classes. 

(a)  Addition  of  necessary  information. 

(b)  Elimination  of  redundant  information. 

(c)  Determination  of  class  and  instance  variables. 

(d)  Identification  of  composite  objects. 

(3)  Organization  of  the  classes  into  a  hierarchy. 

(a)  Analysis  of  the  implementation  language. 

(b)  Construction  of  the  hierarchies. 

(c)  Review  of  the  classes'  variables/methods. 

This  methodology  can  be  easily  applied  to  the  problem  of  designing  the  objects  and  classes 
of  a  computer  microarchitecture. 
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1 .     Identification  of  the  Objects  and  Classes 

a.      Initial  definition  of  the  objects  and  classes 

In  Chapter  I,  the  components  of  computer  microarchitectures  that  are 
common  to  most  computers  were  introduced.  These  include:  register,  memory,  ALU, 
muxs  MAR,  MBR,  shifter,  MIR,  control  store,  and  MPC.  These  components  can  be 
thought  of  as  the  initial  set  of  classes. 

Next  an  initial  definition  of  the  variables  and  methods  associated  with  each 

of  these  classes  must  be  specified.  The  following  is  the  initial  set  of  class  definitions  for 

typical  components  found  in  a  computer  microarchitecture  as  specified  above: 

Class:    ALU 

Variables:         none 

Methods:  and,  or,  not,  math,  zero?,  positive? 

Description:     Represents  a  combinational  circuit;  thus,  it 

has  no  state.    Methods  are  provided  that  perform  logical 

operations  on  a  stream  of  input  data. 

Class:    CONTROL  STORE 

Variables:        varies 

Methods:  load,  read 

Description:     Holds  the  entire  microprogram.  It  must  be 

loaded  with  the  microprogram  prior  to  any  simulation 

execution. 

Class:    MAR 

Variables:         contents  (string  of  bits) 

Methods:  mar,  read,  write 

Description:     Contains  an  address  of  a  MEMORY 

LOCATION  within  a  MEMORY  BANK.  The  method 

mar  accepts  a  control  signal  which  determines  if  a  value  is  to 

be  stored  into  the  MAR. 

Class:  MBR 

Variables:         contents  (string  of  bits) 

Methods:  mbr,  read,  write 

Description:     Models  the  data  interface  to  the  memory 

bank.    The  method  mbr  accepts  a  control  signal  which 

determines  if  the  data  input  will  be  written  to  the  MBR. 

Class:    MEMORY  BANK 
Variables:         contents  (array  of 

MEMORY  LOCATIONS) 
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Methods:  initialize,  load,  read,  write 

Description:  A  read  or  write  to  a  MEMORY  BANK 
implies  a  read  or  write  to  a  specific  MEMORY 
LOCATION  contained  in  the  MEMORY  BANK.  The 
method  load  is  used  to  load  a  user  program  or  data  into  the 
MEMORY  BANK. 

Class:    MEMORY  LOCATION 

Variables:        contents  (string  of  bits) 

Methods:  initialize,  read,  write 

Description:     Used  to  describe  the  contents  of  a  location 

in  a  MEMORY  BANK. 

Class:    MIR 

Variables:         contents  (string  of  bits) 

Methods:  decode,  read 

Description:     Contains  the  various  control  signals.   The 

method  decode  is  used  to  parse  the  register  contents  into 

required  control  fields. 

Class:    MPC 

Variables:  contents  (string  of  bits) 

Methods:  set,  increment,  read,  jump 

Description:  Models  a  microprogram  counter. 

Class:     MUX 
Variables:         none 
Methods:  mux 

Description:  Models  a  combinational  circuit  The  output 
is  one  selection  from  the  many  inputs. 

Class:    REGISTER 

Variables:         contents  (string  of  bits) 

Methods:  initialize,  read,  write 

Description":     Defines  how  the  data  is  represented  in  a 

system,  (i.e.,  how  many  bits  represents  a  register/memory 

location). 

Class:     REGISTER  BANK 
Variables:        contents(array  of  REGISTERS) 
Methods:  initialize,  load,  read,  write 

Description:     Similar  to  a  MEMORY  BANK. 

Class:     SHIFTER 

Variables:         none 

Methods:  shiftjeft,  shift_right,  no_shift 

Description:      Models  a  combinational  circuit.   Methods 

take  a  binary  input  and  perform  a  binary  shift  to  the  left  or 

right. 
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b.      Analysis  Of  The  Object's   Variables 

This  step  looks  at  the  variables  associated  with  the  objects  defined  in  the 
previous  section,  de  Paula  and  Nelson  recommend  looking  for  the  following  (de  Paula  & 
Nelson,  1991,  p.3): 

1)  variables  that  are  common  to  groups  of  objects  (classes) 

2)  variables  having  the  same  value  for  all  objects  of  a  class 

3)  variables  that  can  be  calculated  or  derived  from  other  variables 

4)  variables  that  can  be  decomposed  into  more  elementary  variables 

5)  variables  defined  for  only  a  single  class 

Applying  de  Paula  and  Nelson's  guidelines  to  the  previously  described 
classes,  we  determine  the  following:  The  classes,  REGISTER,  MAR,  MBR,  MIR,  and 
MPC,  all  share  a  common  variable  contents  (guideline  #1  above).  However,  for  this 
application  the  value  of  contents  for  MPC  is  an  integer  value.  Thus,  the  variable 
contents  of  the  class  MPC  cannot  be  treated  the  same  as  the  variable  contents  of  the 
classes  REGISTER,  MAR,  MBR,  and  MIR.  Yet,  the  MPC  class  still  requires  a  read 
method  like  the  previously  mentioned  group  of  classes.  The  classes  CONTROL 
STORE,  MEMORY  BANK,  and  REGISTER  BANK  also  share  the  variable  name 
contents  but  in  this  context  contents  refers  to  an  array  of  the  respective  location  types 
(i.e.,  MEMORY  LOCATIONS  for  MEMORY  BANK,  etc.).  Further  observation 
of  the  class  descriptions  show  no  variables'  to  which  guidelines  #2,  #3,  #4,  or  #5  may  be 
applied. 
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c.      Analysis  of  the  Object's  Methods 

This  step  looks  at  the  methods  associated  with  the  objects  defined  in  the 
previous  section.  The  following  points  should  be  considered  (de  Paula  &  Nelson,  1991, 
pp.  3-4): 

1)  Look  for  methods  that  are  common  to  several  classes. 

2)  Every  concrete  class  should  have,  as  a  minimum,  a  set  of  methods  to  create, 
delete,  maintain,  and  display  its  instances. 

3)  In  order  to  enforce  encapsulation,  it  may  also  be  necessary  to  define  methods  for 
accessing  and  updating  each  variable. 

The  following  is  a  summary  of  significant  observations  made  by  applying 
the  above  design  guidelines  to  each  object's  methods:  The  classes  REGISTER, 
MEMORY  LOCATION,  MAR,  MBR,  MIR  have  the  common  methods  read  and 
write.  REGISTER  and  MEMORY  LOCATION  also  share  the  method  initialize. 
The  similar  classes  MEMORY  BANK,  and  REGISTER  BANK  share  the  methods 
initialize,  load,  read,  and  write.  Also,  the  class  CONTROL  STORE  shares  the 
methods  load  and  read  with  MEMORY  BANK  and  REGISTER  BANK. 
2 .  Refinement  of  the  Objects  and  Classes 
a.      Addition  of  Necessary  Information 

The  methods  BINARY  READ  and  BINARY  WRITE  were  added  to 
the  classes  MEMORY  BANK  and  REGISTER  BANK.  These  classes  require  two 
types  of  read  and  write  methods.  Due  to  programming  concerns  it  is  necessary  to  read 
from  and  write  to  a  storage/memory  location  using  an  integer  or  binary  input.  Therefore 
the  BIN-read  and  BIN-write  methods  were  added  to  these  classes  to  allow  this 
flexibility.  The  binary  version  of  the  read  and  write  methods  use  the  corresponding  integer 
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version  of  these  methods,  by  converting  the  binary  address  to  its  integer  equivalent  and 
calling  the  integer  version. 

Closer  examination  of  the  object  CONTROL  STORE  shows  that  there 
is  still  a  need  to  determine  how  the  microprogram  will  be  represented.  Each  step  in  a 
microprogram  has  the  same  type  of  data,  which  determines  what  control  signals  will  be 
sent.  The  object  CONTROL  STORE  should  be  made  up  of  this  data.  This  data  format 
can  be  clearly  represented  by  introducing  a  new  class,  MICROINSTRUCTION,  which 
will  define  the  various  fields  necessary  to  make  up  a  microprogram  microinstruction. 
Thus,     CONTROL  STORE     will     consist     of    many     instances     of 

MICROINSTRUCTION.  This  new  class  MICROINSTRUCTION  also  affects  the 
class  MIR,  in  that  the  MIR  contains  a  single  MICROINSTRUCTION. 

Examination  of  the  classes  REGISTER,  MEMORY  LOCATION, 
MAR,  MBR,  and  MIR  shows  that  each  of  these  classes  has  the  instance  variable 
contents.  If  one  considers  the  meaning  of  contents  applied  to  each  of  these  classes  it 
becomes  apparent  that  the  value  of  contents  for  an  instance  of  REGISTER,  MEMORY 
LOCATION,  MAR,  MBR,  and  MIR  consists  of  a  single  n-bit  value  (representing  the 
contents  of  a  register),  while  the  value  of  contents  for  an  instance  of  CONTROL 
STORE,  MEMORY  BANK,  and  REGISTER  BANK  will  consist  of  an  array  of 
many  n-bit  numbers  (one  for  each  storage  location).  Each  one  of  these  storage  locations 
can  be  described  by  an  instance  of  that  class  related  individual  storage  type.  This  results 
with  the  instance  variable  contents  containing  an  array  of  REGISTER,  MEMORY 
LOCATION,  or  MICROINSTRUCTION  for  its  corresponding  store  type. 

At  this  point,  a  design  decision  was  made  to  represent  the  instance 
variable  contents  as  a  list.  This  allows  great  flexibility  as  Prograph  provides  very 
powerful  list  primitives.  Representing  contents  as  a  list  allows  the  application  program  to 


32 


represent  storage  locations  with  variable  lengths.  In  the  case  of  REGISTER,  MAR, 
MBR,  MIR,  and  MPC,  where  contents  represents  a  single  binary  number,  contents 
can  be  represented  as  a  list  of  booleans,  where  each  boolean  represents  a  bit  of  the  binary 
number.  In  the  case  of  CONTROL  STORE,  REGISTER  BANK,  and  MEMORY 
BANK,  the  value  of  contents  represents  many  binary  numbers  so  contents  can  be 
represented  as  a  list  of  instances  of  of  the  respective  location  type. 

b.  Elimination  of  Redundant  Information 

Redundant  data  is  simply  data  which  is  not  necessary  to  store  directly  as  it 
may  always  be  derived  from  some  other  data.  There  is  no  redundancy  in  the  data 
maintained  by  the  various  classes  defined  so  far. 

c.  Determination  of  Class  and  Instance  Variables 

The  variables  in  the  classes  discussed  above  have  unique  values  for  each 
instance  of  each  class.  This  means  that  these  variables  can  be  represented  as  instance 
variables. 

d.  Identification   of  Composite  Objects 

There  are  no  variables  in  the  above  mentioned  classes  that  decompose  into 
more  elementary  variables.  Thus,  there  are  no  composite  objects. 
3 .     Organization  of  The  Classes  Into  a  Hierarchy 
a.      Analysis  of  the  Implementation  Language 

The  following  questions  should  be  considered  (de  Paula  &  Nelson,  1991, 
p.2): 

1)  Does  the  system  provide  single,  multiple,  or  selective  inheritance? 

2)  If  multiple  inheritance  is  supported,  what  are  the  conflict  resolution  rules? 

3)  Can  inherited  methods  be  redefined  (overridden)  in  the  subclasses? 

4)  Can  inherited  variables  be  redefined  (overridden)  in  the  subclasses? 
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The  implementation  programs  supporting  this  thesis  are  implemented  in 
Prograph,  an  object-oriented  programming  environment.  Prograph  supports  single 
inheritance  only,  which  answers  question  one  above  and  makes  question  two  not 
applicable.  In  answer  to  question  three,  Prograph  allows  inherited  methods  to  be  modified 
or  redefined,  allowing  the  superclass  to  keep  its  original  definition  while  allowing 
modifications  in  the  subclass  method.  Prograph  also  allows  inherited  variables  to  be 
redefined  which  answers  question  four.  Therefore,  the  object-oriented  programs  for  this 
thesis  will  have  the  following  features:  1)  single  inheritance;  2)  inherited  methods  can  be 
redefined  in  subclasses;  and  3)  inherited  variables  can  also  be  redefined  in  subclasses. 
b.      Construction  of  the  Hierarchies 

In  section  A.l.b  it  was  determined  that  REGISTER,  MEMORY 
LOCATION,  MAR,  MBR,  MIR,  and  MPC  have  the  same  instance  variable 
contents.  These  classes  also  share  several  methods.  The  classes  MAR,  MBR,  MIR, 
and  MPC  represent  specific  applications  of  the  more  general  class  REGISTER  which 
allows  these  classes  to  be  subclasses  of  the  class  REGISTER.  Since  the  classes 
REGISTER  and  MEMORY  LOCATION  share  a  common  instance  variable,  and 
several  methods,  but  share  no  common  superclass,  it  was  decided  to  add  the  abstract  class 
STORAGE  LOCATION.  With  the  class  STORAGE  LOCATION  defined,  the 
methods  initialize,  read  and  write  can  be  moved  up  to  the  STORAGE  LOCATION 
class. 

Further  examination  of  the  above  class  descriptions  also  reveals  that  the 
classes  CONTROL  STORE,  MEMORY  BANK,  and  REGISTER  BANK  share  a 
common  instance  variable  and  many  common  methods,  but  no  common  superclass.  Thus, 
the  abstract  class  STORAGE  BANK  was  defined  as  a  superclass  for  these  classes.  The 
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methods  initialize,  read  write  BIN-read,  BIN-write,  and  load  can  then  be  moved 
up  to  the  STORAGE  BANK  class. 

The  remaining  classes  ALU,  MICROINSTRUCTION,  MUX,  and 

SHIFTER  have  no  commonalities  with  any  other  class,  and  are  therefore  unrelated  to 
other  classes  by  inheritance.  Figure  3.1  presents  the  class  hierarchy  that  results  from  the 
above  discussion. 


<3 

MUX 


microinstruction 


storage  location 


ALU 


shifter 


memory  location    register 


w 


storage  bank 


control  store 


fth 


MAR     MBR       MIR       MPC 


register  bank 


memory  bank 


Figure  3.1  'Generic'  Class  Hierarchy 

We   can   now   present   a  revised   list   of  the   'generic'   computer 
microarchitecture  class  definitions: 


Class:     ALU 

Superclass:  none 

Variables:  none 

Methods:  and,  or,  not,  math,  zero?,  positive? 
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Class:    CONTROL  STORE 

Superclass: 

Variables:         contents: 

(array  of  MICROINSTRUCTIONS) 
Methods:  none 

Class:    MAR 

Superclass:  REGISTER 

Variables:  none 

Methods:  mar 

Class:  MBR 

Superclass:  REGISTER 

Variables:  none 

Methods:  mbr 

Class:    MEMORY  BANK 

Superclass:      STORAGE  LOCATION 

Variables:         contents:  array  of  MEMORY  LOCATIONS 

Methods:  none 

Class:    MEMORY  LOCATION 
Superclass:      STORAGE  LOCATION 
Variables:        none 
Methods:  none 

Class:     MICROINSTRUCTION 
Superclass:      none 
Variables:         instruction  (string  of  bits) 
Methods:  none 

Class:    MIR 

Superclass:  REGISTER 

Variables:  none 

Methods:  decode 


Class:    MPC 
Superclass: 
Variables: 
Methods: 


REGISTER 

none 

set,  increment,  jump 


Class:     MUX 

Superclass: 

Variables:  none 

Methods:  mux 

Class:    REGISTER 

Superclass:  STORAGE  LOCATION 

Variables:  none 

Methods:  none 
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Class:     REGISTER  BANK 
Superclass:      STORAGE  BANK 
Variables:         contents:  array  of  REGISTERS 
Methods:  none 

Class:     SHIFTER 

Superclass:      none 

Variables:        none 

Methods:  shift  left,  shift  right,  no  shift 

Class:     STORAGE  BANK 

Superclass:      none 

Variables:        contents:  array     of     STORAGE 

LOCATIONS 

Methods:  initialize,  load,  read,  write,  binary  read, 

binary  write 

Class:    STORAGE  LOCATION 
Superclass:      none 
Variables:         contents:  string  of  bits 
Methods:  initialize,  read,  write 


c.      Review  of  the  classes*   variables/methods 

The  constructed  class  hierarchy  does  not  introduce  any  unnecessary 
variables  or  methods  in  any  class.  We  believe  that  it  provides  the  basis  for  an  accurate 
model  of  the  real  world  situation. 

B .     IMPLEMENTATION  OF  TANENBAUM'S  MICROARCHITECTURE 

With  the  class  hierarchy  of  a  general  microarchitecture  designed,  it  is  now  relatively 
easy  to  implement  the  design  for  a  specific  microarchitecture.  A  simple  microarchitecture 
presented  by  Tanenbaum  (Tanenbaum,  1984,  pp.  126-149)  can  be  modeled  using  the 
classes  presented  in  section  A.3.b.  A  complete  block  diagram  of  his  microarchitecture 
design  is  reproduced  in  Figure  3.2  below: 
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Figure  3.2  Tanenbaum's  Microarchitecture  (Tanenbaum,  1984,  p.  132) 

1 .     Operation  of  the  Tanenbaum  Microarchitecture 

This  section  is  a  summary  of  the  design  and  operation  of  Tanenbaum's  example 
microarchitecture;  for  more  detail  on  this  design  refer  to  (Tanenbaum,  1984,  pp.  126-149). 
This  microarchitecture  design  is  divided  into  two  main  subsections;  the  datapath  and  the 
control  path.  The  left  side  of  Figure  3.2  is  the  data  path  and  the  right  side  is  the  control 
path.  The  data  path  side  of  this  design  consists  of  a  16  location  register  bank,  AMUX, 
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ALU,  SHIFTER,  MAR,  MBR,  and  memory.  The  bus  width  of  the  datapath  is  16  bits,  all 
registers  and  memory  locations  are  also  16  bits.  Some  of  the  register  locations  are  for 
general  use  and  others  are  for  specific  use;  a  summary  of  the  purpose  of  the  various  register 
locations  is  summarized  in  Figure  3.3. 


Location 

Purpose 

Svmbol 

00 

Program  Counter 

PC 

01 

Accumulator 

AC 

02 

Stack  Pointer 

SP 

03 

Instruction  Register 

IR 

04 

Temporary  Instruction  Register 

TIR 

05 

Zero 

0 

06 

+1 

1 

07 

-1 

-1 

08 

AMASK  (address  mask) 

0FFF  (hex) 

09 

SMASK  (stack  mask) 

00FF  (hex) 

10-15 

General  Purpose  Registers 

Figure  3.3  Microarchitecture  Register  Uses 

Two  of  the  registers  can  be  read  simultaneously  and  placed  on  the  A  and  B 
buses.  The  A  bus  signal  is  fed  into  the  AMUX  along  with  a  signal  from  the  MBR. 
Depending  on  the  control  signal  (0-A  bus,  1-MBR)  to  the  AMUX  (a  simple  two  input 
multiplexer),  one  of  the  two  inputs  will  be  passed  on  to  the  left  input  of  the  ALU.  The 
value  on  the  B  bus  is  fed  directly  into  the  right  input  of  the  ALU.  The  value  on  the  B  bus  is 
also  routed  to  the  input  of  the  MAR,  if  the  control  signal  to  the  MAR  is  TRUE  the  value  of 
the  B  bus  will  be  read  into  the  MAR. 

Two  control  signals,  Fn  and  Fi,  cause  the  ALU  to  perform  one  of  the  following 
operations:  A+B,  A  AND  B,  A,  ~A  (where  A  and  B  represent  the  data  on  the  respective 
buses).  The  ALU  generates  one  data  output  and  two  control  outputs.  The  data  output 
feeds  to  the  input  of  the  shifter.  The  two  control  output  signals  are  Z  (true  if  data  result  is 
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zero)  and  N  (true  ii*  the  data  result  is  negative).  These  two  signals  feed  into  the  micro 
sequencing  logic. 

The  shifter  shifts  the  input  data  one  bit  to  the  left  or  right,  or  it  can  pass  the  data 
through  to  the  C  bus  without  alteration.  The  shifter  has  two  control  signals  as  input.  So. 
and  Si,  The  output  of  the  shifter  is  placed  on  the  C  bus  and  can  be  fed  to  the  register  bank 
and  the  MBR.  The  value  ot  the  C  bus  will  be  loaded  into  the  desired  location  in  the  register 
bank  if  the  ENC  control  is  TRUE.  The  value  of  the  C  bus  will  be  loaded  into  the  MBR  if 
the  MBR  signal  is  also  TRUE. 

The  MAR  and  MBR  in  this  design  can  be  considered  to  be  the  interface  between 
the  memory  and  the  CPV.  When  the  MBR  receives  a  READ  signal  of  TRUE  it  will  read 
the  contents  of  the  memory  location  pointed  to  by  the  MAR  and  place  that  location's  value 
into  the  MBR.  When  the  MBR  receives  a  WRITE  signal  of  TRUE  it  will  place  the  contents 
of  the  MBR  into  the  memory  location  pointed  to  by  the  value  of  the  MAR.  As  discussed  in 
the  introduction,  the  access  speed  of  memory  is  usually  slower  than  the  access  speed  of  the 
CPU's  registers.  In  this  design  it  takes  two  complete  machine  cycles  to  read  from  or  write 
to  memory.  This  means  that  register  access  is  twice  as  fast  as  memory  access. 

This  architecture  uses  a  microcoded  program  to  control  its  components.  The 
micR">pa">gram  is  stored  in  the  Control  Store.  At  the  beginning  of  each  clock  cycle,  the 
contents  of  a  location  (pointed  to  by  the  MPO  of  the  control  store  is  loaded  into  the  MIR. 
The  MIR  is  divided  into  various  fields,  each  field  holding  a  control  signal  for  a  specific 
component.  These  control  signals  are  routed  to  the  various  hardware  components  in  the 
mkiotichitecture.  As  soon  as  the  desired  microinstruction  is  loaded  into  the  MIR.  the 
signals  are  routed  to  these  components  for  the  entire  clock  cycle.  The  status  of  the 
mkxoprogram  is  maintained  by  the  MPC.  After  the  MPC  is  read  its  value  is  incremented 
and  the  result  is  presented  to  the  Mmux.  Two  of  the  fields  oi  the  microinstruction  are  the 
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ADDR  and  the  COND  fields.  The  value  of  the  ADDR  field  is  presented  to  the  input  of  the 
Mmux.  The  Mmux  chooses  between  the  ADDR  and  increment  inputs  for  an  output.  The 
selection  depends  on  the  output  of  the  micro  sequencing  logic  (based  on  the  outputs  of  N 
and  Z)  and  the  value  of  the  COND  read  from  the  MIR.  The  COND  code  is  summarized  in 
Figure  3.4  (Tanenbaum,  1984,  p.  134): 


0  =  Do  not  jump;  next  microinstruction  is  taken  from  MPC  +  1 

1  =JumptoADDRifN  =  l 

2  =  Jump  to  ADDR  if  Z=  1 

3  =  Jump  to  ADDR  unconditionally 


Figure   3.4  COND  Code  Definitions 

This  result  determines  if  the  next  microinstruction  executed  will  be  the  next 
instruction  in  the  control  program's  sequence  or  a  jump  to  some  other  portion  in  the 
microprogram. 

Each  clock  cycle  is  divided  up  into  four  subcycles.  The  following  events  occur 
during  these  subcycles  (Tanenbaum,  1984,  p.  131): 

1 .  Load  the  next  microinstruction  into  the  MIR,  send  control 
signals  to  various  components. 

2.  Gate  registers  onto  the  A  and  B  buses,  increment  the  MPC. 

3 .  Allow  ALU  and  shifter  time  to  produce  stable  outputs  and 
load  MAR  if  required 

4.  Store  the  C  bus  into  the  desired  register  location  if  desired  and 
load  the  MBR  if  required. 

2 .     Design  of  The  Class  Hierarchy 

The  design  of  a  class  hierarchy  to  implement  a  simulation  program  for 
Tanenbaum' s  microarchitecture  begins  with  the  general  microarchitecture  classes  outlined 
in  section  A.3.b.  and  building  from  them  into  a  full  Macintosh  application.  Appendix  C 
contains  the  complete  Prograph  source  code  listing  for  the  simulation  of  Tanenbaum' s 
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microarchitecture.  A  design  decision  was  made  to  allow  the  microarchitecture  to  simulate 
memories  and  registers  with  a  variable  bit  width.  This  allows  for  quicker  test  runs  and  also 
allows  the  simulator  to  model  memories  of  various  sizes. 

a.      Review  and  Modification  of  the  General  Class  Hierarchy 

No  modifications  (from  section  A.3.b)  are  required  to  the  following 
classes:  ALU,  MAR,  MBR,  MIR,  MUX,  MEMORY  LOCATION, 
MICROINSTRUCTION,  REGISTER,  REGISTER  BANK,  SHIFTER, 
STORAGE  BANK,  and  STORAGE  LOCATION.  The  following  classes  were 
modified  (The  revised  'generic'  class  descriptions  are  located  in  Appendix  A): 

Class:    CONTROL  STORE 

modification:  Added  a  load  method  that  invokes  the 
inherited  load  method  from  storage  bank  to  assign 
appropriate  variable  values. 

Class:    MEMORY  BANK 

modification:    1)  Added  a  load  method  that  invokes  the 

inherited  load  method  from  storage  bank  to  assign 

appropriate  variable  values.    2)  Overshadowed  inherited 

methods  read  and  write  (from  STORAGE  BANK)  to 

support  read/write  using  MAR/MBR  interaction  with  the 

memory. 

Class:     REGISTER  BANK 

modification:  Added  a  load  method  that  invokes  the 
inherited  load  method  from  storage  bank  to  assign 
appropriate  variable  values. 

Class:    MPC 

modification:  1)  Added  instance  variables  cycles  & 
counter  for"  simulation  support.  2)  Added  methods  set 
cycles  and  get  counter.  Set  cycles  is  used  to  set  the  cycle 
counter  to  zero  and  store  the  desired  number  of  clock  cycles 
in  an  instance  of  MPC.  The  method  get  counter,  passes  the 
counter  value  of  an  instance  of  MPC  to  its  calling  method 

Class:    MICRO  SEQUENCER 
Superclass:      none 
Variables:         none 
Methods:  generate  signal 
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Description:  Simulates  the  micro  sequencer  component 
of  Tanenbaum's  architectue.  The  method  generate  signal 
sends  a  signal  to  the  mux  for  controlling  logic  and 
addressing  of  the  MPC. 

The  source  code  listing  in  Appendix  C  also  includes  several  other  classes 
that  have  not  been  discussed  thus  far.  These  classes  include:  System,  Application, 
Menu,  Menu  Item,  Window,  sim  and  Time.  The  time  class  is  supplied  in  a  class 
library  provided  by  TGS  systems  (The  TGS  systems  bulletin  board).  This  class  is  used  to 
convert  system  time  to  strings  for  I/O  purposes.  The  'About  Micro  Simulator'  menu  item 
displays  a  dialog  box  that  gives  program  credits  and  the  date  and  time.  The  sim  class  is  a 
class  added  to  the  hierarchy  (inheriting  variables/methods  from  the  class  Window)  which 
contains  methods  that  implement  input/output  for  simulation  purposes.  The  other  classes 
are  all  System  classes  supplied  with  the  Prograph  interpreter/compiler  (TGS  Systems, 
1990,  p.  109).  These  classes  must  be  included  with  any  application;  they  include  the 
attributes  and  methods  necessary  to  handle  menus,  windows,  and  event  control  for  stand 
alone  applications. 

3 .     Design  of  the  Micro  Simulator 
a.      The  user  interface 

The  Micro  Simulator  was  designed  to  be  a  stand  alone  Macintosh 
application.  This  means  that  the  user  interface  consists  of  a  menu  bar  for  controlling  the 
program  and  windows  and  dialog  boxes  for  facilitating  input/output.  The  Menu  Bar  is 
shown  in  Figure  3.5. 
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File                                Edit       Controls 

Load  Memory 
Load  Registers 
Load  Control  Store 
Quit 

Define  Memory 

RIter  Register 

Cycle 

Single  Instruction 

Multiple  Instructions 

Set  MPC 

Run  #  of  Cycles 

• 

Figure  3.5  Micro  Simulator's  Menu  Bar 

Referring  to  Figure  3.5,  the  first  menu  item  under  the  File  menu  is  Load 
Memory.  This  selection  is  used  to  load  a  text  file  that  represents  the  initial  memory  map 
into  the  memory  bank.  A  sample  program  that  can  be  loaded  into  memory  using  the  Load 
Memory  selection  is  presented  in  Figure  3.6. 


#             Opcode 

Macro   Instr 

Comments 

00-0111000000000100 

LOCO   4 

Loads   the   constant   4    into  the  AC 

01-1111010000000000 

PUSH 

Push  the  contents   of  the  AC   onto 

the   stack 

02-0011000000001100 

SUBD   MEM [12] 

Subtract   memory   loc  #12   contents 

from     AC 

03-0101000000000101 

JZER   5 

if  AC  =  0  then   PC    :=   0 

04-0110000000000001 

JUMP    1 

Set   PC    :=   1 

05-0110000000000101 

JUMP    5 

Stay  running  idle 

06-0000000000000000 

07-0000000000000000 

08-0000000000000000 

09-0000000000000000 

10-0000000000000000 

11-0000000000000000 

12-0000000000000001 

Constant    1 

Figure  3.6  Sample  Object  Program  Text  Format 

This  is  a  simple  program  that  loads  the  constant  4  into  the  accumulator  and 
then  pushes  copies  of  it  five  times  on  top  of  the  stack.The  numbers  preceding  the  dash  are 
the  desired  memory  location.  The  numbers  following  the  dash  are  the  instruction  opcodes 
or  memory  values.  These  are  the  actual  values  loaded  into  the  memory.     Any  characters 
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following  the  opcodes  are  considered  comments  and  are  not  loaded.  The  first  column 
following  the  opcode  is  a  macro  description  of  the  preceding  opcode.  The  column 
following  the  macro  description  contains  general  comments.  The  text  file  has  to  be  as  long 
as  the  program  requires,  if  the  program  contains  13  instructions  then  the  text  file  must 
contain  13  lines.  Notice  that  locations  six  through  1 1  have  no  values;  that  is  because  they 
are  used  as  place  holders  for  an  actual  constant  value  at  location  12.  If  these  place  holders 
were  not  used  the  constant  that  should  have  been  loaded  at  location  twelve  would  instead  be 
loaded  at  location  6. 

Referring  once  again  to  the  File  menu  of  Figure  3.5,  the  Load 
Registers  selection  operates  exactly  the  same  as  the  Load  Memory  selection,  except  that 
the  data  is  directed  to  the  Register  bank.  The  Load  Control  Store  selection  similarly 
loads  a  text  file  into  the  Control  Store.  The  Quit  selection  is  used  to  quit  the  Micro 
Simulator  application. 

The  Edit  menu  selection  of  Figure  3.3  is  a  standard  Macintosh  menu  bar 
selection  and  must  be  present  for  all  Macintosh  applications.  For  more  information  on  this 
selection,  refer  to  Inside  Macintosh  Volume  I  (Apple  Computer,  1985,  p.58). 

The  Controls  menu  of  Figure  3.4  is  the  menu  which  implements  the 
features  of  the  Micro  Simulator.  The  Define  Memory  selection  is  used  to  initialize  the 
simulator's  register  and  memory  configuration.  This  selection  causes  a  dialog  box  to  be 
displayed  as  shown  in  Figure  3.7.  The  first  three  entries  are  self  explanatory.  They 
determine  the  width,  in  bits,  of  the  memory/registers  and  the  respective  number  of  locations 
for  each.  MAR  size  determines  the  desired  bit  width  of  the  MAR.  This  allows  the 
simulation  to  limit  the  address  space  allowed  for  the  memory  interface. 
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Figure  3.7  The  Define  Memory  Dialog  Box 

Referring  once  again  to  the  Controls  menu  of  Figure  3.4,  the  Alter 
Register  command  displays  a  dialog  box  which  allows  the  user  to  input  a  desired  register 
location  (by  number)  and  the  new  value  to  load  into  that  register  from  the  keyboard. 
Cycle  causes  the  simulator  to  execute  one  microinstruction.  Single  Instruction  causes 
the  simulator  to  execute  one  macro  instruction.  The  Multiple  Instructions  command 
displays  a  simple  dialog  box  that  requests  the  desired  number  of  macro  instructions  to  be 
executed;  this  causes  the  simulator  to  execute  that  number  of  macroinstructions.  The  Set 
MPC  command  displays  a  dialog  box  which  allows  the  user  to  set  the  MPC.  The  Run  # 
of  Cycles  command  displays  a  dialog  box  asking  for  the  desired  number  of  clock  cycles 
to  be  executed,  then  executes  the  desired  number  of  clock  cycles  and  stops. 

Status  of  the  simulator  is  displayed  in  a  window  (Micro  Simulator)  which 
includes  a  diagram  of  the  data  side  of  the  microarchitecture  along  with  the  values  of  the 
various  components.  A  reduced  copy  of  the  Micro  Simulator  window  is  presented  in 
Figure  3.8.  Any  values  displayed  are  for  the  last  microinstruction  executed. 
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Figure  3.8  The  Micro  Simulator  Window 

The  various  check  boxes  (  ENC,  MBR,  MAR,  etc.)  represent  control 
signals  sent  from  the  last  microinstruction.  An  activated  box  (V  inscribed  in  the  box) 
indicates  that  the  corresponding  control  signal  is  true,  and  an  unactivated  box  indicates  a 
control  signal  of  false. 

The  rectangles  containing  text  display  the  contents  of  the  respective  object 
The  boxes  labeled  A  bus  and  B  bus  indicate  the  values  of  the  respective  buses.  The  smaller 
boxes  above  those  values  indicate  what  register  locations  (by  binary  number)  were  loaded 
on  the  respective  buses.  There  are  also  text  boxes  to  indicate  the  contents  of:  MAR,  MBR, 
and  C  bus  storage  location.  The  text  boxes  associated  with  the  ALU,  AMUX,  and  Shifter 
indicate  the  outputs  of  those  devices.  The  boxes  under  MPC  Last  and  Next  indicate  the 
number  of  the  previous  microinstruction  executed  and  the  number  of  the  next 
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microinstruction  to  execute.  The  Counter  text  box  indicates  how  many  clock  cycles  since 
the  last  time  MPC  was  set.  The  text  box  below  the  Counter  box  presents  the  mnemonic  of 
the  last  complete  macro  instruction  executed.  Two  scroll  boxes  are  used  to  display  the 
contents  of  the  memory  and  register  banks. 

b.     Micro  Simulator  Program  Structure 

The  dataflow  nature  of  Prograph  allows  for  the  Micro  Simulator  program 
structure  to  be  relatively  simple.  As  stated  in  section  B.l,  each  clock  cycle  is  divided  into 
four  subcycles.  A  universal  method  Cycle  is  a  method  that  contains  four  local  operators 
that  each  contain  their  respective  subcycle.  Figure  3.9  presents  the  logical  dataflow 
modeled  by  the  Prograph  source  code.  This  code  simply  gets  the  Micro  Simulator  window 
and  then  executes  each  subcycle  sequentially.  The  dataflow  implementation  automatically 
forces  each  subcycle  (like  a  precedence  graph)  to  run  to  completion  before  the  next 
subcycle  can  execute.  Several  universal  methods  are  provided  to  drive  the  Cycle  method 
for  the  following:  one  complete  cycle,  several  cycles,  and  to  completion  of  a  single  macro 
instruction. 
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Figure  3.9  Cycle  Universal  Method 

Program  state  in  the  Micro  Simulator  is  maintained  by  using  Prograph 
persistents.  These  persistents  are  presented  in  Figure  3.10.  These  persistents  are  initially 
loaded  during  the  execution  of  the  initial  universal  method,  and  get  updated  during  various 
stages  of  subcycle  execution. 
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Figure  3.10  Micro  Simulator's  Persistents 

C.     IMPLEMENTATION  OF  A  SIMPLE  COMPUTER  (ASC) 

Tanenbaum's  microarchitecture  was  easily  implemented  with  few  modifications  using 
the  'generic'  class  design  presented  in  section  A.3.D  of  this  chapter.  The  best  way  to 
fully  test  this  class  design  was  to  implement  an  architecture  of  a  significandy  different 
design.  This  section  introduces  another  architecture  called  "A  Simple  Computer"  (ASC) 
which  is  presented  by  Shiva  (Shiva,  1991,  pp.  220-273).  A  brief  description  of  the  design 
and  operation  of  the  ASC  and  the  implementation  of  its  simulator  using  the  'generic' 
classes  refined  in  section  B  (revised  description  of  'generic'  classes  are  located  in 
Appendix  A)  is  now  presented. 

1       Operation  of  the  ASC  Microarchitecture 

A  simplified  block  diagram  of  the  ASC  is  presented  in  Figure  3. 1 1 .  Like 
Tanenbaum's  microarchitecture,  the  ASC  has  a  datapath  side  and  a  control  path  side.  The 
datapath  side  consists  of  three  buses,  various  registers,  memory  bank  (including 
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MAR/MBR),  index  register  bank,  constant  registers  (1  and  -1  hard  wired)  and  alu.  All 
components  on  the  datapath  side  of  the  ASC  are  sixteen  bits  wide,  and  numbers  are 
represented  using  two's  complement  arithmetic.  BUS1  and  BUS2  direct  data  from  the 
various  registers  into  the  ALU.  BUS 3  directs  data  from  the  output  of  the  ALU  back  to  the 
various  registers. 
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Figure   3.11  ASC  Microarchitecture  Block  Diagram  (Shiva,  1991,  p.229) 

Each  register  (other  than  the  Index  Registers)  is  a  unique  single  entity.  This 
means  that  all  the  appropriate  control  signals  are  routed  to  each  of  these  devices  separately 
(write  to  BUS  1/2,  read  from  BUS3).  It  should  also  be  noted  that  not  all  registers  can  write 
to  both  BUS  1  and  BUS2.  The  design  of  the  microprogram  ensures  that  only  one  register 


51 


at  a  time  writes  to  each  bus.  BUS  1  and  BUS2  also  have  the  sixteen  bit  constant  values  '  1\ 
while  BUS1  also  has  the  sixteen  bit  constant  value  '-1\  These  'values'  act  like  registers 
with  read  only  capability. 

The  ALU  receives  six  signals  from  the  micTocontrol  unit  and  receives  sixteen  bit 
data  from  BUS1  and  BUS2.  Only  one  control  signal  can  be  applied  at  a  time.  These 
control  signals  control  the  following  functionality  to  the  ALU: 

1)  ADD,  add  the  values  on  BUS1  and  BUS2  and  place  the  results  on  BUS3. 

2)  COMP,  take  the  two's  complement  of  BUS1  and  output  the  results  to  BUS3. 

3)  SHR,  shift  the  value  of  BUS1  one  bit  to  the  right,  with  the  high  order  bit 

replacing  the  low  order  bit,  and  output  the  results  to  BUS3. 

4)  SHL,  shift  the  value  of  busl  one  bit  to  the  left,  replacing  the  low  order  bit  with 

zero,  and  output  the  results  to  BUS3. 

5)  TRA1,  directs  the  value  of  BUS1  to  BUS3. 

6)  TRA2,  directs  the  value  of  BUS2  to  BUS3. 

Notice  that  in  the  ASC  design  the  shifter  functionality  is  included  within  the 
ALU.  The  ALU  also  updates  the  value  of  the  PSR  (Processor  Status  Register).  The  PSR 
consists  of  4  bits,  C,  N,  Z,  and  O;  these  values  stand  for  carry,  negative,  zero,  and 
overflow  respectfully.  The  ALU  updates  the  PSR  only  when  the  accumulator  register  is 
written  to.  The  overflow  bit  is  set  when  the  sum  operation  results  in  a  number  larger  than 
215  -1.  The  negative  bit  is  set  when  the  result  of  an  ALU  operation  is  negative.  The  zero 
bit  is  set  when  the  result  of  an  ALU  operation  is  zero.  The  carry  bit  is  set  when  a  carry  out 
from  the  high  order  bit  results  from  an  addition  operation. 

The  MAR  and  MBR  registers  are  used  as  an  interface  between  the  memory  and 
the  CPU.  When  the  MBR  receives  a  READ  signal  it  reads  the  contents  of  the  memory 
pointed  to  by  the  MAR  and  place  that  location's  value  into  the  MBR.  When  the  MBR 
receives  a  WRITE  signal  it  will  place  the  contents  of  the  MBR  in  the  location  of  memory 
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pointed  to  by  the  value  of  the  MAR.  In  this  design  it  takes  two  complete  machine  cycles  to 
read  from  or  write  to  memory  (i.e.,  register  access  is  twice  as  fast  as  memory  access). 

The  ASC  design  supports  four  types  of  addressing;  direct,  indexed,  indirect, 
and  indexed-indirect  addressing  (preindexed-indirect).  The  addressing  modes  are  directly 
controlled  by  fields  of  the  ASC's  macroinstruction.  The  ASC's  microarchitecture  design 
relies  specifically  on  this  macroinstruction  format.  As  mentioned  above,  all  instructions 
used  by  ASC  are  sixteen  bits  wide.  The  ASC's  instruction  format  is  divided  up  into 
various  fields  as  presented  in  Figure  3.12. 


Opcode 
Extension  Bit 

Indirect  Flag      Index  Flag 

Opcode 

Address 

15     14     13     12     11 

10     9      8      7 

0 

Figure   3.12  ASC  Instruction  Format 

This  implementation  of  the  ASC  supports  16  macroinstructions,  thus  four  bits 
in  the  macroinstruction  is  needed  to  describe  the  opcode  (bits  12-15).  Bit  11,  the  opcode 
extension  bit,  can  be  used  to  increase  the  number  of  opcodes  to  32.  Bit  10,  the  indirect 
flag,  is  set  when  indirect  addressing  is  used.  The  two  bit  index  flag  (bits  8  &  9)  has  two 
purposes:  when  the  flag  is  set  to  '00  \  the  index  flag  indicates  that  indexed  addressing 
mode  is  not  in  use;  when  the  flag  is  set  to  the  values  '01'  through  '11 ',  it  indicates  that 
indexed  addressing  is  in  use  with  the  corresponding  index  register.  The  eight  bit  address 
field  (bits  0-7)  is  used  for  direct  addressing,  or  combined  with  the  other  addressing  modes. 
For  a  complete  description  of  the  actual  instruction  set  refer  to  (Shiva,  1991,  p.  193). 

The  control  side  of  the  ASC  microarchitecture  consists  of  a  Microcontrol  unit, 
MPC,  MIR,  Decoder,  and  a  Control  Store.  This  configuration  is  presented  in  Figure  3.13. 
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The  MPC  points  to  the  next  line  of  the  microprogram  to  fetch  (from  the  control  store).  A 
microinstruction  is  21  bits  wide  and  can  be  in  one  of  two  different  formats.  The  formats 
are  distinguished  by  the  high  order  bit.  If  the  high  order  bit  is  zero,  it  is  a  type  zero 
microinstruction.  If  the  high  order  bit  is  1  the  instruction  is  a  type  one  instruction.  A  type 
zero  instruction  actively  sends  control  signals  to  the  various  components  of  the 
microarchitecture;  each  bit  represents  a  control  signal.  A  type  one  microinstruction  uses 
input  status  signals  to  alter  program  flow  of  the  microprogram.  Therefore,  a  type  one 
microinstruction  will  cause  the  MPC  to  be  set  to  some  address  other  than  the  next 
instruction  in  the  control  store.  For  a  more  detailed  description  of  the  microinstruction 
formats  and  control  signal  outputs  see  (Shiva,  1991,  pp.  267-268). 
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Figure  3.13  Block  Diagram  of  ASC  Microcontrol  Hardware 

The  Microcontrol  unit  receives  status  signals  from  the  PSR,  instruction  register 
(IR)  and  index  registers.  Based  on  the  status  signals  and  the  type  of  the  microinstruction, 
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the  microcontrol  unit  will  either  load  a  new  address  into  the  MPC  and  load  a  new 
microinstruction  into  the  MIR,  or  it  will  take  the  present  contents  of  the  MIR  and  decode  it 
into  control  signals,  increment  the  MPC,  and  repeat  the  process. 
2 .     Design  of  The  Class  Hierarchy 

The  design  of  a  class  hierarchy  to  implement  a  simulation  program  for  the  ASC 
microarchitecture  also  begins  with  the  'generic'  microarchitecture  classes  presented  in 
Appendix  A  and  building  from  them  into  a  full  Macintosh  application.  Appendix  D 
contains  the  Prograph  source  code  listing  for  the  simulation  of  the  ASC  microarchitecture. 

a.      Review  and  Modification  of  the  General  Class  Hierarchy 

This  section  reviews  each  class  defined  in  Appendix  A  ('generic'  classes) 
and  describes  the  modifications  necessary  to  implement  these  classes  in  the  ASC  design. 

No  modifications  (from  Appendix  A)  were  required  to  the  following 
classes:  CONTROL  STORE,  MAR,  MBR,  MPC,  MEMORY  LOCATION, 
MEMORY  BANK,  REGISTER,  REGISTER  BANK,  SHIFTER,  STORAGE 
BANK,      and    STORAGE      LOCATION.  The    classes     MUX     and 

MICROINSTRUCTION  were  not  used.  MUX  was  not  used  because  the  ASC  design 
contains  no  mux's.  The  MICROINSTRUCTION  class  was  not  used  because  simple 
instances  of  register  were  used  to  hold  microinstructions.  The  ALU  class  includes 
message  passing  to  the  shifter  class  in  its  math  method.  This  enables  shifter  functionality 
in  the  ALU  in  accordance  with  the  ASC  microarchitecture  design.  The  following  classes 
were  modified  or  added: 


Class:   ALU    (modified) 
modification: 

1)  Added  the  method  overflow  to  determine  if  the  output 
of  the  ALU  is  causing  an  overflow  condition. 

2)  Modified  the  method  math  to  account  for  the  ASC 
specific  functionality  (actual  operations)  including  the 
updating  of  the  PSR. 


55 


Class:    MICRO  CONTROL  (added) 
Superclass:-      none 
Variables:         none 

Methods:  mcu,  read  control  store,  Busl  Data, 

Bus2  Data,  Bus3  Signals, 
ALU  Signals,  Memory  Signals. 
Description:     Contains    methods    to    read    micro- 
instructions,   generate    control    signals,    and    branch 
microprogram  control  flow. 

Class:   MIR   (modified) 

modification:  Added  the  methods  decode  0,  and  decode  1 

to  decode  the  type  zero  and  one  microinstructions. 

Class:    INDEX  BANK  (added) 

Superclass:      STORAGE  BANK 

Variables:         none 

Methods:  zero  index 

Description:     Describes  the  data  structure  and  methods 

necessary  for  implementing  an  index  bank  for  the  ASC.  The 

zero  index  method  generates  a  signal  to  determine  if  the 

contents  of  an  index  register  is  zero. 

Class:  IR  (added) 

Superclass:      REGISTER 

Variables:         none 

Methods:  parse 

Description:     The  parse  method  separates  the  contents  of 

the  instruction  register  into  the  various  fields. 

Class:    PSR  (added) 

Superclass:      REGISTER 

Variables:         none 

Methods:  decode 

Description:     Contains  an  instance  variable  that  maintains 

the  value  of  a  status  register.  Includes  a  method  to  decode 

its  contents  for  use  in  the  microcontrol  unit 


The  source  code  listing  in  Appendix  D  also  includes  the  various  system  classes 
supplied  by  prograph  and  the  class  sim,  as  discussed  in  Section  B.2.a. 
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3 .     Design  of  the  ASC  Simulator 
a.      The  user  interface 

The  ASC  simulator,  like  the  Tanenbaum  simulator,  was  implemented 
using  Prograph  on  the  Macintosh  microcomputer.  This  section  discusses  the  general 
design  of  the  ASC  simulator  and  its  user  interface. 

Figure  3.14  presents  the  menu  bar  for  the  ASC  simulator.  The  ASC 
simulator  application  menu  bar  and  most  of  its  controls  have  the  same  functionality  as  the 
Tanenbaum  micro  simulator  menu  bar.  Since  the  ASC  does  not  use  a  general  purpose 
register  bank,  the  Alter  Register  menu  selection  under  the  Controls  menu  was 
removed.  This  menu  selection  allows  the  user  to  enter  a  value  from  the  keyboard  by 
entering  the  register  number  and  its  new  value.  The  Register  menu  was  added  to  the 
menu  bar  to  enable  keyboard  entry  changes  for  the  program  counter  (Update  PC). 


File                                Edit       Controls 

Register 

Load  Memory 
Load  Registers 
Load  Control  Store 
Quit 

Define  Memory 

Cycle 

Single  Instruction 

Multiple  Instructions 

Set  MPC 

Run  #  of  Cycles 

Update  PC 

Figure   3.14  ASC  Simulator's  Menu  Bar 

The  File  menu  is  exactly  the  same  as  the  Tanenbaum  Micro  Simulator, 
and  its  selections  provide  the  same  functionality.  The  required  data  format  for  the  input  text 
files  is  also  the  same.  The  Edit  menu  selection  contains  the  standard  Macintosh  editing 
features. 

The  Define  Memory  function  was  changed  because  the  ASC  simulator 
was  designed  to  operate  with  a  fixed  memory/register  bus  width  of  16  bits.  Also,  since  the 
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ASC  uses  individual  registers,  there  is  no  need  to  specify  the  required  number  of  registers 
in  the  register  bank.  This  selection  still  initializes  the  memory  bank  to  the  desired  number 
of  memories.  This  resulted  in  a  Define  Memory  Dialog  Box  with  one  input,  'Enter 
Desired  Number  of  Memories:'.  This  dialog  box  is  presented  in  Figure  3.15.  All  other 
menu  selections  have  the  same  functionality  as  the  Tanenbaum  micro  simulator. 


Define  Memories 


Enter  Desired  Number  of  Memories: 


20 


{ 


OK 


Figure  3.15  The  Define  Memory  Dialog  Box  (ASC) 

Status  of  the  simulator  is  displayed  in  a  Window  (Micro  Simulator)  which 
includes  a  diagram  of  the  data  side  of  the  microarchitecture  along  with  the  values  of  the 
various  components.  A  reduced  copy  of  this  window  is  presented  in  Figure  3.16.  The 
values  in  the  various  boxes  indicate  the  value  of  the  respective  components  after  each 
microinstruction  is  executed.  Several  new  items  were  added:  MIR,  Index  Bank,  CNZV 
(PSR),  and  the  constant  values  (1  and  -1).  The  CNZV  output  gives  the  status  of  the  PSR, 
while  the  constant  values  are  placed  on  the  associated  input  buses  by  the  micTocontrol  unit. 
The  MIR  box  gives  the  bit  string  of  the  last  microinstruction  executed. 
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Figure   3.16  The  ASC  Simulator  Window 

b.     ASC  Simulator  Program  Structure 

The  ASC  simulator's  main  program  uses  the  universal  method  Cycle  (as 
in  the  Tanenbaum  simulator),  but  the  ASC's  design  does  not  use  subcycles.  The  Cycle 
universal  method  is  the  main  program  and  brings  together  all  the  various  classes'  methods 
to  work  as  a  complete  simulator.  The  other  universal  methods  used  in  the  Tanenbaum 
simulator  were  also  integrated  seamlessly  in  the  ASC  simulator  (generic  conversions 
between  bit  strings  and  boolean  strings,  etc).  Program  state  is  maintained  by  using 
Prograph  persistents  (see  Appendix  D). 
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D.     COMPARISON  OF  THE  TWO  SIMULATORS 

Both  architectures  possess  many  similarities.  Their  designs  have  a  classic  layout  that 
consists  of  a  data  path  and  a  control  path.  The  data  path  side  consists  of  some  type  of 
register  configuration  (including  a  program  counter,  instruction  register,  and  accumulator), 
memory  with  a  MBR/MAR  interface,  buses,  and  a  two  bus  input  ALU.  The  data  path  side 
for  these  architectures  is  16  bits  wide.  On  the  control  side,  both  architectures  have  a 
control  store,  MPC,  and  MIR.  Both  architectures  use  a  microprogram  to  control  their 
various  components  for  the  execution  of  macroinstructions.  Since  they  both  use  a 
microprogram,  their  macro  level  instruction  set  can  be  expanded  or  changed  by  altering 
their  respective  microprograms.  With  respect  to  the  implementation  of  the  simulators,  both 
designs  use  the  same  format  for  textfile  input  of  the  macroprogram  to  the  memory.  Both 
simulators  allow  altering  the  microprogram  by  loading  the  control  store  with  a  textfile 
representing  the  microprogram. 

Although  the  Tanenbaum  and  ASC  designs  are  very  similiar,  there  are  also  some 
differences  in  their  designs.  One  major  difference  between  the  Tanenbaum  design  and  the 
ASC  design  is  the  layout  of  the  registers.  With  the  ASC,  each  register  (other  than  the 
Index  Registers)  is  a  unique  single  entity.  This  means  that  all  the  appropriate  control 
signals  are  routed  to  each  of  these  devices  separately  (write  to  BUS  1/2,  read  from  BUS3). 
The  Tanenbaum  design  uses  a  bank  of  registers  which  allows  two  registers  at  a  time  to 
send  their  values  to  the  A  and  B  Buses  and  one  register  to  receive  the  contents  of  the  C 
Bus.  The  registers  are  selected  by  sending  the  appropriate  register  numbers  to  the  register 
bank.  Thus,  the  ASC  design  requires  many  more  control  signals  to  manipulate  the 
registers.  In  the  ASC  design  not  all  registers  can  write  to  both  BUS1  and  BUS2,  while  the 
Tanenbaum  design  allows  the  same  operations  for  all  registers.  The  design  of  the 
microprogram  ensures  that  only  one  register  at  a  time  writes  to  each  bus.  The 

60 


implementation  of  ASC  requires  individually  initializing  each  of  the  separate  registers, 
where  the  Tanenbaum  simulator  simply  inializes  the  entire  register  bank  with  one  operation. 
In  the  ASC  design,  BUS1  and  BUS2  also  have  the  sixteen  bit  constant  values  *1\  while 
bus  1  also  has  the  sixteen  bit  constant  value.'-l'.  These  'values'  act  like  registers  with  read 
only  capability.  The  ASC  design  uses  an  index  register  bank  to  support  indexed 
addressing.  The  functionality  of  the  index  bank  is  similar  to  the  Tanenbaum  register  bank. 
This  required  the  addition  of  the  index  bank  class  in  the  ASC  simulator.  This  class  was 
added  to  support  the  additional  functions  of  indexed  addressing. 

While  both  designs  support  direct  addressing,  other  addressing  modes  are  not  shared 
by  the  two  microarchitectures.  The  Tanenbaum  design  supports  immediate  addressing  and 
includes  a  stack,  along  with  stack  operations  such  as  push  and  pop.  Immediate  addressing 
is  supported  completely  through  the  microprogram.  The  implementation  of  the  stack  does 
not  require  any  special  simulator  features  except  a  register  reserved  for  a  stack  pointer 
(which  is  a  general  register  in  the  Tanenbaum  design)  and  the  appropriate  microprogram 
support. 

The  ASC  design  supports  direct,  indirect,  indexed  addressing,  and  indexed-indirect 
adressing.  Direct  addressing  is  similiar  to  the  Tanenbaum  design.  Indirect,  and  indexed 
addressing  is  supported  by  adding  the  method  parse  to  the  new  class  IR  (Instruction 
Register).  The  parse  method  decodes  special  fields  that  direct  the  Microcontrol  unit  to  use 
indirect,  direct,  or  indexed-indirect  addressing. 

The  microinstruction  format  of  the  two  designs  differs  of  course,  but  how  the  formats 
are  used  is  also  different.  In  the  Tanenbaum  design,  all  microinstructions  are  of  the  same 
type;  a  microinstruction  is  decoded  and  the  various  control  signals  are  sent  to  all  the 
components.  Part  of  the  microinstruction  field  contains  a  conditional  that,  based  on  the 
microsequencer  output,  will  cause  the  Mmux  to  branch  the  microprogram  or  go  to  the  next 
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microinstruction.  In  the  ASC  design,  there  are  two  types  of  microinstructions:  a  type  zero 
microinstruction,  which  sends  control  signals  to  the  various  components;  and  a  type  one 
microinstruction,  which  controls  branching  of  the  microprogram.  This  difference  in  the 
microinstruction  format  required  various  additions/alterations  to  the  'generic'  classes.  The 
MIR  class  was  modified  to  support  the  decoding  of  the  two  types  of  microinstructions. 
The  class  MICRO  CONTROL  was  added  (in  lieu  of  the  MICRO  SEQUENCER  class 
which  was  removed  from  the  Tannenba um  simulator)  to  support  the  microcontroler 
functionality  specific  to  the  ASC  design.  This  type  of  change  would  be  required  when 
switching  between  any  different  architectures.  In  the  ASC  design  the  Micro  Control  unit 
makes  all  deciscions  involving  branching;  this  eliminates  the  need  for  a  Mmux  as  found  in 
the  Tanenbaum  design. 

The  execution  of  macroinstructions  also  differs  between  the  two  designs.  The 
Tanenbaum  design  loads  the  macroinstruction  into  an  instruction  register.  As  the 
microprogram  progresses,  the  macroinstruction  is  shifted  to  the  left.  The  microprogram 
branches  to  different  locations  based  on  the  value  of  the  most  significant  bit  of  the 
macroinstruction.  This  means  that,  depending  on  the  size  of  the  opcode  of  the 
macroinstruction,  the  microprogram  can  branch  for  up  to  8  cycles  to  parse  the 
macroinstruction  (the  largest  opcode  is  8  bits).  The  decoding  of  an  ASC  macroinstruction 
is  a  much  shorter  process.  The  macroinstruction  is  fetched,  and  placed  in  the  instruction 
register.  The  opcode  of  the  macroinstruction  matches  the  address  of  the  microcode 
required  to  execute  the  macroinstruction.  This  results  in  a  slightly  larger  microprogam,  but 
fewer  cycles  are  needed  for  each  macroinstruction.  These  differences  are  accounted  for  in 
the  respective  simulators  by  microcode  and  their  respective  objects  (MICRO 
SEQUENCER  in  Tanenbaum,  and  MICRO  CONTROLLER  in  ASC). 
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The  Tanenbaum  design  sends  three  signals  to  the  micro  sequencer:  N  (ALU  output  is 
negative);  Z  (ALU  output  is  zero);  and  COND  (microprogram  branching  conditions  based 
on  N  and  Z).  The  ASC  design  is  slightly  more  complicated.  It  maintains  a  PSR 
(Processor  Status  Register)  that  has  several  bits  (C,  N,  Z,  and  O  as  discussed  in  section 
C.l)  representing  the  status  of  the  number  in  the  accumulator.  There  are  more  inputs  to  the 
micro  controller,  PSR,  IR,  and  Index  Registers  contents.  These  differences  are  supported 
in  the  respective  classes  MICRO  SEQUENCER  and  MICRO  CONTROLLER. 
Also,  the  classes,  IR,  and  PSR  with  associated  methods  were  added  to  the  class 
hierarchy  for  the  ASC  simulator. 

The  two  designs  have  different  ALU  functionality  in  that  they  have  different  inputs 
and  operations.  The  Tanenbaum  design  has  two  different  components,  an  ALU  and  a 
Shifter.  The  ASC  combines  the  functionality  of  these  two  components  into  the  ALU.  The 
method  overflow  was  added  to  the  class  ALU  and  the  math  method  was  altered  to 
provide  the  required  functionality  for  the  ASC  design.  In  the  ASC  design,  messages  (from 
within  the  ALU  methods)  are  sent  to  the  shifter  object  to  give  the  effect  of  the  shifter 
residing  inside  the  ALU. 

Both  designs  have  several  small  variations  in  some  of  the  objects  as  discussed  above. 
The  various  objects  are  brought  together  to  form  a  complete  simulator  via  the  main 
program.  Since  these  simulators  differ,  the  main  programs  differ.  The  main  programs  for 
both  simulators  are  called  'cycle'  and  are  implemented  as  universal  methods  (in  Prograph). 
The  user  interfaces  differ  in  appearance  (because  the  buses  and  components  differ),  but  the 
approach  for  the  construction  of  the  user  interfaces  are  exactly  the  same.  Their  menu  bars 
and  dialog  boxes  are  almost  the  same;  this  allowed  a  great  deal  of  code  to  be  reused.  These 
two  simulators  were  designed  by  first  considering  the  Tanenbaum  design,  making  'generic' 
classes,  and  then  producing  the  Tanenbaum  simulator.  The  ASC  simulator  was  designed 
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by  taking  the  'generic'  classes  previously  derived  and  applying  the  changes  necessary  to 
give  ASC  functionality.  This  process  could  have  easily  been  reversed  with  very  little 
inpact  on  the  final  result 

E.     SUMMARY 

A  'generic'  class  hierarchy  was  designed  for  the  application  of  simulating  a  general 
purpose  computer  microarchitecture.  A  simple  computer  microarchitecture  (Tanenbam's) 
was  introduced  in  which  a  simulator  was  designed  and  built  using  this  'generic'  class 
hierarchy.  Few  modifications/additions  were  required  in  building  the  Tanenbaum  simulator 
from  the  'generic'  classes.  To  further  test  the  'generic'  class  design,  a  second  computer 
microarchitecture  was  introduced  (Shiva's)  in  which  a  simulator  was  designed  and  built 
using  the  refined  'generic'  class  hierarchy  arrived  at  when  designing  the  Tanenbaum 
simulator.  Once  again  it  was  discovered  that  few  modifications  were  required  in  the  refined 
class  hierarchy  when  extending  its  use  in  another  simulator. 
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IV.   SUMMARY,  CONCLUSIONS  AND  RECOMMENDATIONS  FOR 

FUTURE  RESEARCH 

A.     SUMMARY 

Chapter  I  developed  the  need  for  simulation  of  computer  architectures  at  various 
levels.  It  introduced  the  notion  that  architecture  simulation  could  be  more  easily 
implemented  using  object-oriented  design  and  programming.  The  chapter  further 
developed  object-oriented  concepts  by  giving  basic  definitions  and  terminology.  Basic 
microarchitecture  components  and  operation  were  then  described  using  an  example 
microarchitecture.  Finally,  Prograph,  an  object-oriented,  visual,  data-flow  language  was 
introduced,  along  with  a  basic  description  of  its  syntax  and  use  applied  to  object-oriented 
programming. 

Research  areas  related  to  this  thesis  were  discussed  in  Chapter  II.  These  areas 
included:  architecture  simulation  for  educational  purposes,  class  hierarchy  design  for 
simulation  of  multimicrocomputers,  object-oriented  approach  to  VLSI  routing,  object- 
oriented  approach  to  interactive  user  interface  for  microprogram  simulators,  and  work 
being  done  using  object-based  languages  such  as  Ada.  Several  of  these  papers  pointed  out 
that  the  design  of  the  class  hierarchy  is  a  crucial  portion  of  the  design  of  any  simulator. 
There  is  a  definite  interest  in  the  areas  of  classroom  instructional  simulators  using  object- 
oriented  programming  languages  with  reusable  software  components  and  an  easy  to  use 
user  interface.  As  of  yet,  however,  there  is  no  work  encapsulating  all  of  these  concepts 
simultaneously.  This  provided  the  motivation  for  this  research. 

Chapter  III  showed  how  an  existing  object-oriented  design  methodology  was  used  in 
designing  a  'generic'  class  hierarchy  to  implement  the  components  of  the  basic  computer 
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microarchitecture  introduced  in  Chapter  I.  Tanenbaum's  microarchitecture  design  and 
operation  was  then  introduced.  The  'generic'  classes  were  used  in  the  development  of  a 
microarchitecture  simulator  using  Tanenbaum's  microarchitecture.  It  was  found  that  very 
little  modification  to  the  existing  'generic'  class  hierarchy  was  required  in  implementing  the 
Tanenbaum  simulator.  The  design  and  operation  of  Shiva's  ASC  microarchitecture  was 
also  introduced.  A  simulator  for  this  microarchitecture  was  implemented  to  further  test  the 
usefulness  of  the  'generic'  microarchitecture  class  hierarchy.  Once  again,  only  a  few 
modifications  to  the  'generic'  class  hierarchy  were  required  to  implement  this  simulator. 
The  design  and  implementation  of  the  two  simulators,  including  the  user  interfaces,  were 
also  discussed. 

B.     CONCLUSIONS 

Object-oriented  programming  provides  a  natural  environment  for  modeling  and 
simulation  problems.  This  is  because  the  implementation  details  are  hidden,  allowing 
objects  to  reflect  the  real-world  environment.  A  careful  class  hierarchy  design  is, 
however,  essential  to  the  development  of  any  object-oriented  program. 

'Generic'  classes  can  be  created  to  simulate  the  various  objects  found  as  components 
in  most  computer  microarchitectures.  Careful  design  of  these  component  objects  allows  the 
reuse  of  the  code  for  many  different  simulators.  This  was  demonstrated  through  the 
development  of  simulators  for  two  different  microarchitectures.  In  implementing  the  two 
simulators,  it  was  still  necessary  to  write  a  'main'  program  that  puts  the  various  'generic' 
objects  together  to  form  a  complete  simulator. 

It  was  also  found  that  components  like  ALU's,  which  are  peculiar  to  each 
architecture,  require  complete  remodeling;  there  was  very  little  code  reusability.  Parts  of  an 
ALU  model  can  be  reused,  like  adders,  but  the  control  signals  are  normally  different 
enough  to  warrant  a  complete  redesign. 
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Each  simulator  required  slightly  different  user  interfaces;  however,  these  user 
interfaces  had  almost  identical  menus  and  functionality.  They  only  had  a  different  depiction 
of  the  buswork  and  components. 

The  microarchitecture  simulators  were  implemented  in  Prograph,  a  visual,  object- 
oriented,  data  flow  language  operating  on  the  Macintosh.  It  was  found  that  although  there 
was  an  initial  learning  curve  (to  adapt  to  the  unaccustomed  nature  of  the  pictorial  syntax), 
Prograph  made  the  implementation  of  the  class  hierarchy  for  the  simulators  relatively  easy. 
Prograph's  application  builder  (used  to  generate  user  interfaces)  allowed  rapid  development 
of  the  user  interfaces.  Another  advantage  to  Prograph  is  that  it  is  relatively  inexpensive  and 
readily  available. 

Shiva's  ASC  microarchitecture  simulator  was  demonstrated  to  an  introductory 
computer  organization  class  studying  the  ASC  microarchitecture.  The  class  found  the 
simulator  to  be  quite  helpful  in  learning  the  concepts  of  the  architecture  as  they  could  trace 
through  complex  microinstructions  in  a  short  period  of  time  without  having  to  keep  track  of 
all  of  the  parameters. 

C.     RECOMMENDATIONS  FOR  FUTURE  RESEARCH 

There  are  several  areas  of  research  that  logically  follow  from  this  work.  As  is  often 
the  case  in  research,  more  questions  were  raised  than  answered.  With  a  basic  'generic' 
class  hierarchy  designed,  it  is  possible  to  pursue  experimenting  with  'families'  of 
architectures.  The  object-oriented  approach  should  prove  to  be  ideal  for  this  too  in  that  one 
should  be  able  to  implement  the  'lowest'  member  of  a  family  (such  as  the  68000 
microprocessor  in  the  series  of  680x0  microprocessors)  and  inherit  the  features  of  that 
architecture  as  one  moves  to  other  more  advanced  members  of  the  same  family. 

Even  though  this  research  was  performed  using  Prograph,  which  was  found  to  be  an 
excellent  language  for  the  development  of  these  systems,  it  should  also  be  very  interesting 
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to  investigate  other  object-oriented  (or  object-based)  languages  for  implementing 
microarchitecture  simulators  and  comparing  the  development  effort  with  the  results  of  this 
thesis. 

The  simulators  in  this  thesis  used  text  files  representing  the  object  code  of  the 
macroprograms  and  microprograms.  The  micro/macroprograms  were  assembled  by  hand 
and  represented  in  the  text  file  using  ones  and  zeros.  The  usefulness  of  the  simulators  can 
be  increased  by  developing  micro/macro  assemblers  which  would  generate  text  files 
compatible  with  the  simulators  developed  in  this  thesis.  It  should  be  possible  to  use  object- 
oriented  techniques  to  develop  'generic'  classes  which  model  various  assemblers  for 
different  simulators. 

Although  these  simulators  were  very  useful  for  classroom  instruction,  simulators  are 
most  often  used  in  designing  actual  systems.  For  a  simulator  to  be  useful,  it  is  necessary  to 
build  into  the  components  some  automatic  monitoring  functions.  An  example  would  be  a 
counter  that  determines  how  many  times  memory  is  accessed  for  each  macro  level 
instruction  execution.  One  could  also  include  in  each  object  a  facility  to  maintain  an 
'execution  history'  that  would  record  the  usage  of  components  and  the  frequency  of  each 
component's  use. 

As  previously  mentioned,  a  new  ALU  class  had  to  be  designed  and  coded  for  each 
microarchitecture  implementation.  Research  into  designing  a  'generic'  class  hierarchy  in 
support  of  ALU  design  would  be  another  area  of  challenging  research.  This  would  require 
the  specification  of  control  signal  inputs,  functions  based  on  control  signals,  and  status 
outputs.  All  vary  greatly  among  different  ALU's. 

With  growing  interest  in  multiprocessors,  it  would  be  logical  to  persue 
multiprocessor  simulators.  This  would  require  investigating  timing  effects  of  all  operations 
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involving  each  component.  After  obtaining  timing  information,  new  data  structures  will 
have  to  be  introduced  to  account  for  timing  constraints. 

Finally,  the  development  cycle  when  using  the  simulator  to  design  a  microprogram 
could  be  shortened  by  integrating  a  microprogram  editor  with  the  simulator.  Presently  the 
programmer  is  required  to  write  the  microprogram,  load  it  into  the  simulator,  and  then  run 
the  simulator.  The  user  then  has  to  evaluate  any  required  changes,  stop  the  simulator,  edit 
the  microprogram  text  file  and  repeat  the  process.  This  could  be  simplified  if  the  simulator 
were  integrated  with  a  microprogram  editor. 
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APPENDIX  A 

This  Appendix  contains  the  revised  'generic'  classes  derived  when  implementing  the 
Tanenbaum  design  microarchitecture  simulator. 

Class:     ALU 

Superclass:      none 

Variables:         none 

Methods:  and,  or,  not,  math,  zero?,  positive? 

Description:     Represents  a  combinational  circuit;  thus,  it 

has  no  state.    Methods  are  provided  that  perform  logical 

operations  on  a  stream  of  input  data. 

Class:    CONTROL  STORE 

Superclass: 

Variables:         contents: 

(array  of  MICROINSTRUCTIONS) 
Methods:  load 

Description:  Holds  the  entire  microprogram.  It  must  be 
loaded  with  the  microprogram  prior  to  any  simulation 
execution. 

Class:    MAR 

Superclass:      REGISTER 

Variables:         none 

Methods:  mar 

Description:     Contains  an  address  of  a  MEMORY 

LOCATION  within  a  MEMORY  BANK.   The  method 

mar  accepts  a  control  signal  which  determines  if  a  value  is  to 

be  stored  into  the  MAR. 

Class:  MBR 

Superclass:      REGISTER 
Variables:         none 
Methods:  mbr 

Description:  Models  the  data  interface  to  the  memory 
bank.  The  method  mbr  accepts  a  control  signal  which 
determines  if  the  data  input  will  be  written  to  the  MBR. 

Class:    MEMORY  BANK 

Superclass:      STORAGE  LOCATION 

Variables:         contents:  array  of  MEMORY  LOCATIONS 

Methods:  load,  read,  write 

Description:     A  read  or  write  to  a  MEMORY  BANK 

implies  a  read  or  write  to  a  specific  MEMORY 

LOCATION  contained  in  the  MEMORY  BANK.  The 
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method  load  is  used  to  load  a  user  program  or  data  into  the 
MEMORY  BANK. 

Class:    MEMORY  LOCATION 

Superclass:      STORAGE  LOCATION 

Variables:         none 

Methods:  none 

Description:     Used  to  describe  the  contents  of  a  location 

in  a  MEMORY  BANK. 

Class:     MICROINSTRUCTION 

Superclass:      none 

Variables:         instruction  (string  of  bits) 

Methods:  none 

Description:     Defines  data  structure  that  describes  a 

microinstruction. 

Class:    MICRO  SEQUENCER 

Superclass:      none 

Variables:         none 

Methods:  generate  signal 

Description:     Simulates  the  micro  sequencer  component 

of  Tanenbaum's  architecture.  The  method  generate  signal 

sends  a  signal  to  the  mux  for  controlling  logic  and 

addressing  of  the  MPC. 

Class:    MIR 

Superclass:      REGISTER 

Variables:  •      none 

Methods:  decode 

Description:     Contains  the  various  control  signals.  The 

method  decode  is  used  to  parse  the  register  contents  into 

required  control  fields. 

Class:    MPC 

Superclass:      REGISTER 

Variables:         counter,  cycles 

Methods:  set,  increment,  jump,  set  cycles, 

get  counter 
Description:     Models  a  microprogram  counter. 

Class:     MUX 
Superclass: 
Variables:         none 
Methods:  mux 

Description:     Models  a  combinational  circuit.  The  output 
is  one  selection  from  many  inputs. 

Class:    REGISTER 

Superclass:      STORAGE  LOCATION 

Variables:  .      none 
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Methods:  none 

Description:     Defines  how  the  data  is  represented  in  a 

system,  (i.e.,  how  many  bits  represents  a  register/memory 

location). 

Class:     REGISTER  BANK 

Superclass:      STORAGE  BANK 

Variables:        contents:  array  of  REGISTERS 

Methods:  load 

Description:     Similar  to  a  MEMORY  BANK. 

Class:     SHIFTER 

Superclass:      none 

Variables,  "      none 

Methods:  shift  left,  shift  right,  no  shift 

Description:     Models  a  combinational  circuit.   Methods 

take  a  binary  input  and  perform  a  binary  shift  to  the  left  or 

right. 

Class:     STORAGE  BANK 
Superclass:      none 
Variables:        contents: 

array  of  STORAGE  LOCATIONS 
Methods:  initialize,  load,  read,  write,  binary  read, 

binary  write 

Description:  Defines  data  structure  and  methods  for 
modeling  a  general  storage  object.  Allows  for  access  using 
both  integer  and  binary  address  references. 


Class:    STORAGE  LOCATION 

Superclass:      none 

Variables:        contents:  string  of  bits 

Methods:  initialize,  read,  write 

Description:     Provides     methods     for     accessing 

(read/write)  a-  storage  location  in  a  memory  or  register  bank. 
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APPENDIX   B 

This  appendix  contains  a  sample  user  session  for  the  Micro  Simulator  and  the  ASC 
Simulator. 
Tanenbaum  Micro  Simulator: 

The  Micro  Simulator  is  started  by  double  clicking  on  the  application  icon  labeled  Micro 
Simulator.  This  causes  the  application  to  load,  the  initialization  of  the  menu  bar,  and  the 
following  dialog  box  to  appear: 


Define  Registers  &  Memories 

Register  IDidth: 
Number  of  Registers: 
Number  of  Memories: 
MRR  Size: 

16 

12 

20 

12 

7 S1 

OK 

i L 

The  user  is  required  to  enter  values  for  each  field  in  the  dialog  box  (the  above  values  are 
defaults).  After  all  values  have  been  entered,  the  user  presses  the  Enter  key  or  clicks  the 
OK  button.  In  this  example,  the  Register  Width  field  configures  the  simulator  to  have  a  16 
bit  data  path  for  buses,  registers,  and  memory.  The  Number  of  Registers  and  Number  of 
Memories  fields  configure  the  simulator  to  have  the  respective  values  simulated.  In  this 
case,  12  registers  and  20  memories  have  been  selected.  The  MAR  Size  field  specifies  the 
number  of  bits  the  MAR  will  use  for  addressing  the  memory.  These  bits  are  the  low  order 
bits  passed  from  the  data  path  to  the  MAR;  this  example  specifies  a  12  bit  MAR. 

The  Tanenbaum  design  uses  a  set  of  registers,  including  general  purpose,  special  purpose, 
and  constant  values  (registers  6,  7,  8,  and  9).  Register  values  can  either  be  loaded  into 
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their  respective  registers  individually  by  using  the  Alter  Register  command  (discussed 
below),  or  they  can  be  loaded  from  a  text  file  by  using  the  Load  Registers  command  in 
the  File  menu.  To  initialize  the  registers  using  a  text  file,  select  the  File  menu  (click  or 
command- J),  its  choices  are  shown  below: 


Load  Memory       3€L 


Choose  the  Load  Registers  selection  (this  can  be  done  by  either  clicking  with  the  mouse 
or  using  the  command-J  key  sequence).  This  action  displays  the  file  selection  dialog  box 
as  shown  below: 


g  Micro  6TT] 


D  decrement. ene 
D  program. asm 


D  register.set 


D  stack. asm 


O 


o 


DirectDriue 


I-  je<  t 


Iliiue 


Open      ) 


Cancel    j 


Select  the  name  of  the  text  file  that  represents  the  desired  register  configuration  (in  this  case 
register.set).  There  are  no  restrictions  on  naming  conventions  for  any  text  files 
associated  with  this  simulator.  The  two  buttons  Eject  and  Drive  are  disenabled  (cannot 
be  used)  because  there  were  no  other  drives  mounted  during  this  example.  The  contents  of 
the  register.set  text  file  is  shown  below: 


0-0000000000000000 
1-0000000000000000 


Program  Counter 
Accumulator 
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2-0000000000000000 
3-0000000000000000 
4-0000000000000000 
5-0000000000000000 
6-0000000000000001 
7-1111111111111111 
8-0000111111111111 
9-0000000011111111 


Stack  Pointer 

Instruction  Register 

Temporary  Instruction  Register 

0 

+  1 

-1 

AMASK   OFFF    (hex) 

SMASK   00FF    (hex) 


The  text  file  format  for  both  register  and  memory  descriptions  is  the  same:  any  number 
(representing  the  location  or  address),  followed  by  a  dash  ('-'),  followed  by  l's  and  0's 
(which  represent  the  bit  string),  followed  by  a  comment  The  numbers  in  the  text  file  are 
for  the  use  of  the  programmer  only;  the  simulator  loads  all  binary  strings  in  order  starting  at 
location  zero.  The  results  of  loading  this  text  file  into  the  simulator  are  shown  in  the 
register  scroll  box  below  (found  in  the  simulator  window,  this  example  shows  locations  5- 
10). 


05-0000000000000000 
06—0000000000000001 
07—1111111111111111 
08—0000111111111111 
09—0000000011111111 
10-0000000000000000 


o 


o 


Next,  load  an  object  code  program  into  the  simulator's  memory  (this  is  a  text  file 
previously  saved).  This  is  done  by  choosing  the  Load  Memory  selection  from  the  File 
menu  as  shown  below  (by  clicking  or  command-L  key  combination): 


Load  Memory 


Load  Registers     d£J 
Load  Control  Store 
Quit  d§Q 


This  causes  the  file  input  dialog  to  be  displayed.  Selection  of  the  decrement.exe  file  is 
shown  below: 
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gj  Micro  6"T| 


D  decrement. ewe 


D  program. asm 
D  stack. asm 


G 

<=>DirectDriue 

o 

1:  je<  t 

Oi  h»« 

Open 

Cancel 

The  decrement.exe  program  is  a  simple  program  that  loads  a  constant  '4'  into  the 
accumulator,  pushes  it  onto  the  stack,  decrements  the  accumulator  value,  and  continues 
four  more  times.  After  completing  this  task  the  program  remains  idle  by  reaching  step  '5' 
and  then  continuously  branching  back  to  step  '5'.  The  text  file  of  this  program  is  shown 
below: 


00-0111000000000100 

LOCO 

4 

Loads  the  constant  4 

01-1111010000000000 

PUSH 

Push  AC  onto  the  stack 

02-0011000000001100 

SUBD 

MEM [12] 

Subtract  memory  loc  #12 

03-0101000000000101 

JZER 

5 

if  AC  =  0  then  PC  :=  0 

04-0110000000000001 

JUMP 

1 

Set  PC  :=  1 

05-0110000000000101 

JUMP 

5 

Stay  running  idle 

06-0000000000000000 

** 

07-0000000000000000 

** 

08-0000000000000000 

** 

09-0000000000000000 

** 

10-0000000000000000 

** 

11-0000000000000000 

*  * 

12-0000000000000001 

Constant  1 

Now  that  the  program  is  loaded  into  the  memory,  it  is  necessary  to  determine  where  the 
stack  pointer  will  point  (recall  that  only  20  memory  locations  were  defined  in  this  example). 
In  this  example  the  initial  stack  pointer  location  will  be  initialized  to  *  11 '.  This  is  done  by 
using  the  Alter  Register  command  under  the  Controls  menu.  This  operation  is  shown 
below: 
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Controls 


Define  Memory  3€D 


Alter  Register 


Cycle  3€S 

Single  Instruction  §€1 

Multiple  Instructions  3€R 

Set  MPC  88 M 

Run  #  of  Cycles  3§N 


Selecting  the  Alter  Register  operation  displays  the  dialog  box  below.  We  want  to 
change  the  stack  pointer  (register  2)  to  a  value  of  eleven.  A  2  is  entered  in  the  Register 
Number  field,  and  the  appropriate  string  of  l's  and  O's  are  entered  into  the  Register 
value  field.  Press  the  Initialize  Register  button  to  enter  the  value  into  the  register.  The 
dialog  box  will  remain  displayed  so  that  other  entries  can  be  made.  Press  Done  to  remove 
the  dialog  box. 


Initialize  Registers 


Register  Number:      [2 
Register  Ualue: 


0000000000001011 


Initialize  Register 


Done 


At  this  point  the  user  program  is  ready  is  ready  to  execute.  Execution  can  proceed  by  one 
of  several  methods  which  are  selected  from  the  Controls  menu.  The  Cycle  command 
causes  the  simulator  to  execute  one  microinstruction.  The  Single  Instruction  command 
causes  the  simulator  to  execute  the  necessary  microinstructions  to  complete  one 
macroinstruction.  The  Multiple  Instructions  command  displays  a  dialog  box 
requesting  the  desired  number  of  macroinstructions.  The  user  enters  this  value  and  the 
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requested  number  of  macroinstructions  are  executed.  The  dialog  box  for  this  operation  is 
shown  below: 


The  Set  MPC  command  of  the  Controls  menu  is  used  to  reset  the  MPC  to  an  input 
value  (to  alter  microprogram  flow).  The  dialog  box  for  this  operation  is  shown  below: 


The  Run  #  of  Cycles  command  of  the  Controls  menu  displays  a  dialog  box  similar  to 
the  Multiple  Instructions  command,  except  the  simulator  executes  the  desired  number 
of  micToinstructions. 

The  sample  program  can  be  run  with  any  combination  of  the  above  commands.  The 
diagram  below  shows  the  contents  of  memory  after  the  decrement.exe  program  has  run 
to  completion: 
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00—0111000000000100 
01—1111010000000000 
02—0011000000001100 
03—0101000000000101 
04—0110000000000001 
05—0110000000000101 
06-0000000000000000 


07—0000000000000001 


08—0000000000000010 
09—0000000000000011 
10—0000000000000100 


15 


Referring  to  the  above  figure,  it  shows  that  the  numbers  4,  3,  2,  and  1  were  loaded  into  the 
memory  locations  10, 9,  8, 7  respectively.  Notice  that  the  first  location  loaded  by  the  stack 
pointer  is  10  (recall  that  the  stack  pointer  was  initialized  to  1 1).  This  is  because  the  stack 
pointer  is  decremented  before  the  value  is  written  into  memory.  The  above  figure  also 
shows  that  location  7  is  highlighted;  the  simulator  highlights  the  last  value  written  to  (in 
both  the  register  and  memory  banks). 

ASC  Simulator: 

The  ASC  simulator  is  very  similar  to  the  Tanenbaum  simulator.  Most  of  the  menu 
operations  have  the  same  effects.  The  following  is  a  sample  session  with  the  ASC 
simulator. 

The  simulator  is  started  by  double-clicking  on  the  icon  named  ASC.  This  causes  the 
application  to  load,  the  menu  bar  to  initialize,  and  the  following  dialog  box  to  appear: 
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Define  Memories 


Enter  Desired  Number  of  Memories: 


20 


OK 


This  dialog  box  simply  initializes  the  number  of  memory  locations,  in  this  case,  20.  In  this 
simulator  the  bus,  register,  and  memory  widths  are  hard  coded  to  16  bits.  All  of  the 
registers  have  specific  purposes,  as  discussed  in  the  thesis  body. 

The  next  step  is  to  load  the  sample  program  into  memory.  This  is  done  by  selecting  the 
Load  Memory  command  from  the  File  menu  as  shown  below: 


Load  Memory     Ml 


Load  Control  Store 
Quit  3§Q 


This  action  displays  the  file  selection  box  shown  below: 
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( 

^IflSC 

<& 

D  RSC  Design  Notes 
D  flSC. micro 

O 

DirectDriue 

D  decrement. mac 

*           j 

D  increment. mac 
D  programl.mac 
D  program2.mac 

O 

Urwe 

Open 

Cancel 

Selecting  the  decrement.mac  text  file  as  shown  above  (previously  saved  text  file)  loads 
the  text  file  contents  into  the  memory.  The  contents  of  decrement.mac  are  shown  below. 
This  program  loads  the  accumulator  with  the  value  '15'  (located  at  memory  8).  It  also 
loads  index  register  #1  with  the  value  '5'.  It  places  the  contents  of  the  accumulator  into  the 
memory  locations  1 1-15,  then  the  program  repeats.  This  simulator  uses  the  same  type  of 
text  file  formats  as  the  Tanenbaum  simulator.  Similar  actions  can  be  executed  by  choosing 
Load  Control  Store  from  the  File  menu.  This  will  load  a  microprogram  represented  by 
the  text  file  into  the  control  store. 


00-0001000000001000 
01-1100000100000111 
02-0010000100001010 
03-1111000100000010 
04-0101000000000001 
05-0000000000000000 
06-0000000000000000 
07-0000000000000101 
08-0000000000001111 
09-0000000000001001 


LDA  W/MEM[8] 

LDX  INDEX  1  W/MEM[7] 

STA  10, 1 

TDX  INDEX  1  BRA  2 

BRU  1 


CONST  5 
CONST  15 
CONST  10 


At  this  point  the  program  is  ready  to  execute.  The  ASC  program  execution  controls  operate 
with  the  same  functionality  as  the  Tanenbaum  simulator.  The  Controls  menu  is  the  same 
as  the  Tanenbaum  Controls  menu  except  there  is  no  Define  Memory  selection.  This  is 
because  only  one  register  can  be  altered,  the  program  counter  (PC)  register.  The  PC  can  be 
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altered  by  choosing  the  Update  PC  selection  from  the  Registers  menu.  The  dialog  box 
resulting  from  this  selection  is  shown  below: 


Enter  Desired  Register  Ualue: 


0000000000001111 


OK 


Using  the  various  controls  (as  discussed  in  the  Tanenbaum  Example)  the  program  is  then 
run  to  completion.  The  memory  contents  after  execution  are  shown  below: 


06-0000000000000000 
07—0000000000000101 
08—0000000000001111 
09—0000000000001001 
10-0000000000000000 


11—0000000000001111 


12—0000000000001111 
13—0000000000001111 
14—0000000000001111 
15—0000000000001111 


o 


Memory  locations  11-15  contain  the  value  initially  loaded  into  the  accumulator  15. 
Memory  location  1 1  is  highlighted  because  it  was  the  last  memory  value  written  to. 
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APPENDIX  C 

This  appendix  contains  the  source  code  for  the  Tanenbaum  design  microsimulator. 
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G3  cycle  1:1  O  subcycle  4  1:1  (Si  update  Mbr  1:1 


*}»»»»»»»»>>»»»»»»»>* 


tmn  tnm*  G5S550 


win  fmm        mum 

...     ^  *  "" 

fc,:.;-,UM:;....,^ra 


t>'rwr>»»»#»)»)»»»»TnTK 


E3  binary-string  1:1 


vrminimmfimni}imirrrm 


ESP 

TUT 


E 


v,s,,,,„,,,„,M,,m»)mmm*k 


Thw.  Aug  IS,  imi  14  It 


I  binary-tiring  1:1  O  blnary-atcil  1:3 


tmnnmmmnnmmmmwn 


TKOt    [x] 


mmmnmmmmmmnmm 


O  binary-ttring  1:1  Q  binary-aicli  2:3 


vnmiuninmanmmmtam 

T 


C3  binary-tiring  1:1  O  b.r.«ry-«»c.i  3:3 


■v.-i-.-y.-y.-^-r^.-^w 


E^T2 


t>!»»»mm»fi»imi<im»l!i\ 

\\      •rrer    m    DMSnr-a»OU 


Q  string-binary  1: 


wrmmmni'immmmmm 


*,'.i,I.M.UJ.>~™r*//)*~~r*~-*/*/*<'l 


tiring-binary  1:1  O  atcii-blnary  1:3 


.;.,.,.,.,„.,.,U.„„„„„„„^1 


I'lLfEl 


O  firing-binary  1:1  O  awli-blnary  2:3 


TKUI 


•  1  Omni  Ita     Tlw  A<*  l$.  IMl  if  it 


62  tlnng-binery  1:1  O  atcii-binary  3:3 


vmrmmmmqrmmniijTTm 


ummmmm&mmmmrim* 


§1     arret   in  wctf-OmarY 


C3  Initialize  1:1 


«3 

iDHlgj,  |«t|«||H|.||  ,»||  g] 


fit  t  «€*«*««*  «»> 


IB 


§1  ftgnir  «tw* 

§2  Micro   Simulator 

§3  Pernor)    Scroti 

$4  R«gr*l«r   Scot 


G3  del  left  1:1 


M»»>»»»»»jm 


z 

»»»»»» 


u'l'iffi'vifm'm'mrmfi  vr* 


G3  del  left  1:1  O  Hernoue  1:1 


Thw.  Aug  15.  1*91  14  19 


C2  initial  1:1 


'"■  "'•••■•'>•••  ■•■•'■•  •>  •>  •>  •>  -"Trm 


*■■-«.'■: a 


§1    TMicre  Smiatoi*  ■Soup'  "MBMu  Ragnwn-  11PC  wraW  ■About  NPS  Wen   inwilaoO 


CD  About  Micro  Sim  1:1 


v»»m>^)m»„m»»j}j)mm 


lEiOnptfy  TOT-  j| 


5'    Aoout  NPS  UKra  Smjblor 


E3  Room  Micro  Sim  1:1  O  Display  Oatc  1:1 


m»»r»wiw»>>rm»jn>»rrrm 


■-'"       ""I 


f»»»»»»»»»»»»»»»rr*n 


E9  About  Micro  Sim  1:1  O  Dltploy  Time  1:1 


t»»m»»»»»»>»>m»»rrTm 


fr'—'K     551   TrST-T^ 


r/*r?yw}??j}?)f?f?fr?ir}rm?7mn 


%  i  QmM  una      Thu.  Aug  IS.  IMi  14  1* 


APPENDIX  D 

This  appendix  contains  the  source  code  for  the  ASC  design  microsimulator. 


133 


&  Cla 


TIM*  ^^»tflW«^ 

^      ^     ^y>      ^ 

Application      «*ny      ktefkU     Ham     »!««•« 


■Mara     control 
»IU  .1.111. r 


Inttai    Mnh 
•ry    oonk 

'•f  !••♦'     oank 


$ 


7  PSR 


SI 


Ouvus     C    N.  Z.  O 
Oncnvoor     DM  paj  Mm  to  owcwt 
,,     oontoma  ol  p*> 


I  PSft/decode  1:1 


M' MM  Homo 


J>  o     o    a 

C-^^     N     \Z\0 


moots       ConVoi  (Tffj.  Bwo  fhpvt 
OuTDUD  Nona 

Ooocnpuon    if  control  •  TRUE  o*i 
out  meal  nto  tfio  mbr 


(  ) 


7  MIR 


38  MBR 


ASCI  PO£      Fn    Aug  It.  W<  ««• 


E2  MtR/mbr  1:1 


w»m»mmmmm»»mmrm 


•nmmnmsBBma, 

jc^mmt  In 

m»ii  »m 


►wis    srvT 

HfJ— I 
mnnmmmnmmmimrrrrt. 


•  •Hum* 


V  MflH 


39  MAR 


¥ 


V  regioci 


I  regltter 


fSTl      MM     Moral 
ll¥l     owp«   »»o- 


B3  ngitttr/riad  low  I: 


„.,.,.....,..,,.,.,.,„........„„ 


*?  <>}>}»>}}}> 


SBBBSBi 


V  ttoroge  location 


▼ 

««  Alt)  At  l 


MCI  PCS      9t\.  Atjg  1«    1«1  «0? 


I  ttoragc  location 


El 

inn 

El 


mpuB      SB*   am  Nam* 
Out>w«   »lo**a«  Location  mtWCJ 


input*.      Stora  Nam* 
Output*   ConiMtt 


@) 


inpua      fttor*  Hum 

Otapwn  Con»mi 


storage  lotahon/read  1:1 


^T_ 


O  (forage  location/write  1:1 


7.'J.V,W/VM'/fW>>W.'/'/J 


ti<»»»»»»»m»»ii»/»»rm 


E3  tlorege  locoiion  inn  1:1 


G3  storage  locetion/init  1:1  O  build  lit!  1:1 


,,.,.,.,.,.,.,.,.,„,,.,,,.,„.rr7^ 


ASCI  POS      f  n    Aaf  II.  IMt  I  <M 


V  memory  lOCitlon 


WHIMII 


memory  location 


V  MIR 


ty 


Si 


El 


m  MlR/oetooe  0  1:1 


■/■J  •ijuiimu  •rwmwi,  jjj  -rm 


Item  gwrn-Mj 


TVr 

2    jW'm-ih»2 


ALU  en  }      ■»  2     ISn  1 


UCIMl      H    1^  II     !■<  IIS 


E3  MIR/dtcodc  I  l: 


V 

••Mania 

0 

V 

0 

V 

••wfiiar 


V   MPC 


Ouvwn     «<MPC>» 


El 


OuVMM     Goum*.  Gonwm 
Dm cnpf#i    u«m  mpc  Mmio 
mn  maw  o*  cmiw 


input     mUKm  Bu»h 


ONCftffiDfl      R*J*Mto  QOMMfttB 


]fy,|      DMCrpuon     Um  UPC  BM  NflH 
•  •<    evct«««nribui* 


£2  HPC/tncr«m«nt  1: 


ASCI  PG6      Ffl.  Awg  Iff,  INI  •<» 


E2  MPC/Jump  1:1 


vnmafimmmmimiamio 


trmimmrminnimmmaa 


E2  MPC/««t  1:1 


C»K     »lo..g 

^ 

i 

•  UPC     Hor.  § 

E3  MPC/sct  eyelet  1:1 


found  •  of  CwoM 


g5?c 


"71—- --" 
.  a— tu 


z: 


tmmmmmtihinmnnmim 


&2  MPC/get  counter  1:1 


(jure    ll«r.a 


ttiitiitiiinmlttmtiiittiimm 


•sci  pos    Pn.  •*■  it,  i«i  •« 


V  Urn 


■•HI 

FMJC 


V 


nut 

-•-■IT 

TRJt 

MHl 

Mil 


(  XX)  300  | 

■In 


V 


( ) 


Atci  rot    m  M|  i».  wi  •  <* 


PnHWi     DtWMw  «MfM*  I  Ail     *•*•  MPC  w"*,,w 

MMM  MPC  •«rV  Oato*  *»  ligl        OaacftWo*      OMOMM  UPC  MM 

I,,     UPC     fan  "«  MfcM  ptaoad  r  mpc  *ntrf 


«    Wta    •xnuWIO'     IWdPW 
Iflpltt        ..«MM» 


Ovipv*  <iWMto» 


BCUvalt    Dawwwi      AOMM  NMM       ••M.lvftl*  <>"*»"      Owaww  window 


ioiit.1    icoi 


Serai  •**»  nam*  u»  ••■••«  ro  n  «m  tnpul  i 


■  a      >-gi.i«i  o^    Win* 

SI  2r.^rr        01 

clival*   Ommon     mmm  »««»      mimim 

El  —  SKT     SI 

lii-icrai 

SI  ■ 

tatog  boi   upg— 

»gr*t*>»  and  mam 
Jao  cans  w>*t*UB 
ifN        nou*      «wn»».  Nam.  oau  <im)      f^'Tl 

ml      »*-»  «"■«  K¥| 

Uil         DaacnptKm      ia>4ataa  Mil  tarn  -        '*  *   ~ 
"'•■",lu»9«w  wmonr  wn  tap*  aampa."***1*"1"1 

II? I      0-p«»    Booawmaavnei  aa.)  TUI       ^^^     ^a, 

,,,.,..      Omopw    DwawiMiai  »  a  1 1  I   F 


,NMR>»  ~~]J        DaactipnOfi      AOMM  Mwp  MlDg  !»■ 

Dm (ajjaa     aaa»  npui  nw  1  It*! 

iniiiaTTak*****!  wm.  <mm  ■— i— l  fauna 


OuajMBj  ««wra» 
Oh 

Mata-lMiafla 


sai-num    ••iwnww  w»«at*>airlnf 


upOaun  ikmimi 

Ml  m    Mid  I 
ainrifl    Mpwt 


twax.     ««w«aoan»,  Ham   Data  «*<■ 
Daacmnon   updawa  a  (Mcwt  aam 

a  ai/MQ  a*  twaQa* 


SI  ~:2~z--' —  SI 

'••'••••H?*!**1"'',"V  •«     lai 

Oaacrswon     ia>dB*aa  any  anmasw 

^^    •.«  mmi  ^^ 

tf^t      Ocorcwon    D—M  PC  \nH      "**"    """  ""■»■  ■"" 

I  fq»l      aaiog  boi  gna  m  «*»  I  I*t»I      Omwi     nut  a  »«i 

1*1    airing 

(j»T|       DaauM**''   Kfcll 


PC  <uog  «»■ 
t*l  pc  crtpcl— 


E3  tlm/ttt  tent  1:2 


*mm»m»»R»»»»mmnm 


UCI  PG8      f n    Aaa  tl.   <«i   IO' 


•  im/tet  (CHt  2:2 


,r»,r-m!>>r>»h»mrmr»rrnr> 


C3  nm/Set  MFC  1:1 


^MPC 


V.  *qwww 


j^imwo*!     W 


Bn»«-ii»»a 


*l""' 


JEE3 


»m»»mmmmmmmm»K 

§1     Micro  Simulator 


£3  tim/get  mpc  1:1 


V!i»r^>>mmi^umim^nm 


upc   wiMn 


^■trW/Ott      Wih«»w%1 


E55D 


wmwmmmmmmmr* 


A*C1  POE      Fn    Aug  It.  1M<  lot 


O  •Im/initiallzt  rtgister  1:1 


v»,»»>,»>»»g»}»>»rjf»jm 


/E.."..a      ^ 


Jf  QUIT       »«wfc/wrif| 


r. ■■ ...a 


91     r*gi*«r   **»*• 
V3     r»flai#*    MM* 


623  iim/get-num  1:1 


■— «r — ■ 

E 


3L 

g.>.~j."-ia 


Not 


1Y.Y,Y.Y.Y,& 


C2  slm/lnltiil  valuts  1:1 


ywwyjm 


€5&*5 


rt|lil>t       —  wry     ittn 


IM«1      MM* 


1  rv^i  l 


■ rc 


ASCt  POt     Fn  amj  it    >•»>  in 


ED  sim/imtioi  value*  1:1  O  Initialize  Memory  l/o  registers 


^^■■/■■■■■■'■■■■■■■■■■■■■■■■■■■■■'■■■m 


$1     f"Sfi  WIT  "MAR  WIT) 
62    Mtcro  StmuWw 


C3  sim/inltlal  values  1:1  O  Clear  Mite  displays  1:1 


wj*rmimmrirjryf}>r?rr7r?rrF777i 


•  2 

a 

WAN 


tsr7rimrr?r7mmTjrM*jf?rmr9i 


%\    tmir  i«it*  -s««i  Mir  "Bvft2  u*r  -AU.I  win 

12     Micro  SimuUor 


G3  sim/define  1:1 


Wqwmm 


nrtuini'i'ttm 


ASCI  PCS     Fn.  Aug  I*    1M1  •  12 


tlm/update-tcroll  I  1 


tmmmmmmmimmimiai 


£3  tlm/updste-ttrell  1:1  O  build-line  1:2 


v»r»r!»»m»»ii»»»t{>yTTm 


A1C1  K*       Mugll     IKill) 


E3  •Im/updale-icroll  1:1  O  build-line  2:2 


cnssmEmZsznnnnnna 


O  sim/initial-tcroll  1:1 


f»m»»)»»»»»»»»»»rrrrr. 


ED  tlm/inltial-scroll  1:1  (01  bulld-linct  1:2 


«o  pos    rn.  Aug  it  tm  •  14 


O  iim/inilioi-»troll  1:1  O  build-lino  2:2 


G3  tim/Eel  window  1:1 


&ppnc«n* 


2—2 


tim/uD06ie-u«iue  1:4 


1^1 


* — 7\  <f 


t»»»»»»»r*»»»»»>»»Trr> 


E3  tim/updalr-value  2:4 


e>'»'>»>>>>}>»*}>!f>fn>}»irTfH 


Atct  rat    m.  *•«  it,  m  •  is 


G3  tlm/updtlc-ualuc  3:4 


nmm>i!t!im»»»»»mmmi 


G3  um/updale-UDluc  4:4 


vimtamtftm^imnm^ma 


w/.v.v.v.v.v.y.'/V.v.v.v/.v.v.v.vj 


nm/ietting  1:1 


„........,.,.,.....,.,.,.,..„.yrm 


■55553 

2EEBZBZ 


rssssssssssssss>>ssssJJJJ?SJJJJJJMi 


©  tlm/ttt-tetting  1:1 


giTntTiuijra 


_ 


E2  tlm/updale-wttger  1:1 


»i\v»i»!»m<ty»»>m>i»nm 


ASCI  POS      Ffl.  Aug  It    Iftl  t  It 


G3  ilm/updata-ttrlng  1:1 


4ii»njnj,...„li,.„i>m>imntk 


E3  aim/activate  1:1 


tmmmmmtyowmmnnT, 


\jjian    wi»«»»3     |T»ui  1 


•^~"' 


T/.-r.'rwr/,,,,,7,trrr/r,r/r,r/T7rj\ 


•  im/fltaciiuata  I: 


mmmmmm^mmmmrm 


&i/a»i    ann««»  I 


5° 


mtf/?j??rrrrrrrrrj*mrrfrffrr77m 


63  um/upoete-eait  1: 


A1C1  «Jt     >n   A«|  i«    iaai  •<? 


O  urn    npdttr  pc  I: 


•mmmmimmmmmiuim 
|1 


K'lgliUKwrlli  i 


.0-  |Mlkl*l 

■i—-^"1" ■ 

%.,„/.cj,....^ 


:"■••■"■">•>'■"■• "W™"» 


§1     R«gsl*r  incATt 

',.:■    Chinq*  A«9«air 
§3    Micro  SimuMtoi 


E3  tim/get  pc  window  1:1 


»s 


$1     Micro  SimuMor 
§2  Crung*  ntgiWif 


G2  tlm/gei  ttrtng  I: 


vummmaimimimaimim 


t»r»m»m»>}>n))»»i)>»rm 


V  index  bank 


^ 


a«ci  ras    fii.  *««  it.  itti  •  it 


SO  ! 


0    (rkg#1  DmiWiuii     Owtw*  mamm  •<  1MH 
mmi  impmtt  i  tare 


index  bank/zero  Index  t: 


BjBgajBfflggggjBHgajB^Bj 

Mm 


"»"'Y»«a 


TriM  f  0 
»m»mm»ttmm»»»»mnk 


V 


«•«"««!• 


y  in 


SI 


Ovoutt      MMH  Indu.  IM  Opoooa 
Dttaetton     km*  »  atoto  to  ovtovt  tot 


IR/poric  1:1 


viiimiimiimtwimi/imtna 


EilWirtf  J3 


B55ES51      ' 

E£t»IH-wlh23 


l«»"'"jl 


p   w   V 


V  micro  control 


ASCI  ros      Fn   Aag  It,  1M1  •  it 


IS  5 

El 

II     Oi 

SI 


(jgj  micro  control 

OuVmAS     0— W  «  Control  Mx» 
Ometfo*    l—H  ©*  UPC  MM. 

M<    ••v*ir«H     lUn  looailofl 


Bu.i     0«U 


I0DMW        Akl   IMUI     PSA 


•u«3    Signals  ooam 


E) 

El 

E) 


Cmwcw    rh*  Gorrmr  Mr**  » 

QIHIf  Bus  2  arm  r  inn  or 
p-1t  oontxoi  MT>   UCAttOA   0WK*B 


OtOIS     THAI    TKA3  ADO   COM* 

•HL.SHB 
OHOIprM     Quill— ■  ALU 
ALU   Orfflatri    Corwumli 


*J|  OiAMB    nun  wrft>  (IHnliml 

I  l?l  DwrWM     Ormralra  RAO  odwoi 

M«mor,     signals    &lgnab 


E3  micro  control/mcu  1:1 


W'lfmt     rntnl     »wg] 


G3  micro  control/mcu  1:1  O  Procott Type  1  Microinstruction  1:1 


KS,ftVSU:W/*Y/SMUU//U«M>'^D 


rtcroAdorrjfa 


lEupof  MIR/MPC  Papain  H 


\t\lpcm<m  OmtHriW 


miimiiiiiiiiiimimitu. 


=0 


G3  micro  control/mcu  1:1  O  Procett  Type  1  Microinstruction  1:1  O  Updttc  MIR/MPC  displays  1:1 

vm/mmmmummmiuim 


■^ — f  -Mr  — r 


HPC    InnM 


E2 


B? 


4>»}>»»m»»»mmm»m»* 

%\     Hero   MflWIMT 


AtC!  KQ6      rn    Aug  IS.  iRi  »i 


C3  micro  control/mcu  1:1  (EZ  Proem  Type  I  Microinstruction  1:1  O  branch  1:9 


,^y., .,.,„„„„„,,„„„„„„„„„„„„.,„ 

V  ^  \  ^  \ 

FALSE    [x]       FALSI    |k|       I1LM    |k1 


KMI»C»w.ll.a 


ii>m»imn'm»r»i»»»rnm 


E)  micro  control/mcu  1:1  O  Procott  type  1  Microinstruction  1:1  O  bronch  2:9 


1  catto-opcccc 
tkue  [mJ  i>ui  (xj         iuu  (xj 

UPC    sura        / 


^MPC/w.ii."^ 


O  micro  conlrol/mcu  1:1  O  Pioctn  Type  I  Microinttruclion  1:1  O  branch  9:9 


FALSE  |xj  THUf  [5]       "i»«  l*J 


lMPC<lncr»»>nl| 

■ 711 " 


FALSE    [XT        k*>C     Sl*n 


Aviiii 


t)!j»»»!»i!»»m>m»mrrTr* 


asci  ras    rn.  Aug  if  tan  ib 


E3  micro  control/mcu  1:1  O  Process  Type  1  Microinstruction  1:1  O  bronch  4:9 


VMifjitiiiiitflii. 


•nMmigiiMt(mt. 


OnM  I  acc  «-0 


TRUE    [xj  T»U€    \*]  FALSE    IXj 


■  M>C/ln«r»ni.flll' 


^l4->»»»„,,„„„„„„^t|       t  - 


SS»C       Sl.r. 


tmrmmmmtnmmnmrrm 


O  micro  conlrol/mcu  1:1  O  Process  Type  I  Microinstruction  1:1  O  branch  5:9 


v!»W»»>W>»»'g»»»t>>m       OraMi  •  ACC  -0 
FALSE    [xj      PALM    [Xj      \         TUI   [xj 


Kniie/w.ii.a 


"l"'"""  ■'  wmmmmtmm. 


E2  micro  control/mcu  1:1  O  Process  Type  I  Microinstruction  1:1  O  bronch  6:9 


vurmmmmmmitmmgm 


niuE  |xj  false  [xj         raw  (xj 

I' 


Ji    Mcrocoo*  ohm  arena  •  oata«o    miim 


MCI  KB      Fit.  A*  IS.  IS01  tit 


I  micro  control/mcti  1:1  O  Process  Type  1  Mlcrolmlruclion  1:1  O  branch  7:9 


wmrwrmnmmt. 


?  'U'    » 

I.*-"1    *'  S**'    \ 

E5p5lX*JESmS3 

ESMPC/»rll«a 
mtmtmtmmmmnmmm* 


O  muro  conlrol/mcu  1:1  O  Proctf t  Type  1  Microinstruction  1:1  O  branch  8:9 


vimjliiimmmii^timigim    im  ■  zercmnocjui 


'    S    ■    ■ 


-* — ■ — -        E 


linmm     Irv 


>v  ■ 

__i 

i^,„,.,...».»B""'j-'"»i 

ftia*r      li*n  ^ 


Tni«  t  0  tl<-' 

[Cl 


M»C     »!••♦ 


E"'c'-'°"'a 


« •>•>•>•>•>,>•>»»,,  .,„.,„.„*> 


O  micro  conlrol/mcu  1:1  O  Proem  Type  I  Microinstruction  1:1  O  bronch  9:9 


|1 


„.,.,.,.,•„,,,„  u  u  „,„„»„m 


Branch  ttcaJ  mm  Mcto  uuwlitfui  Ml  •>  dmmi  i 


E3  micro  conlrol/mcu  1:1  O  Process  Type  1  Microinstruction  1:1  O  Update  Display  1:1 


„.„„,„„„„„„„„„„„„„„> 

»•  mre  »'«■» 

\        H..I    H>C  / 

\ — ■ —  jg^sa 

^  \       F  MS  niwn»  — ""^ 

n*^*  p  ft  rf^**1"* 

■■'"'"»',•"-"■■ 

ti-mmmmmmmmmmm 


ASCI  POS      (n    Aug  If.  1*11  •« 


C3  micro  control/mcu  1:1  O  Proem  Type  I  Microinstruction  1:1  O  Update  Display  1:1 


Ql     Micro  Swuwc 


E3  micro  control/read  control  store  1:1 


mmnmmmimmmimmrm 
MFC     Start 


HjUPClt»t*% 


Si 


et      •!•'•"••« 


iContctm 

MB— ML— 


StoriQ*  todJtK. 
DHfjM 

1 


5'     conuoi  »tof» 
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